idnits 2.17.1 draft-ietf-ipp-collection-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 Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** There are 79 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([RFC2568], [RFC2616], [RFC2569], [IPP-IIG], [RFC2911,RFC2910], [RFC2910], [RFC2911], [RFC2565,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. == There are 2 instances of lines with non-RFC6890-compliant IPv4 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 37: '...ent specifies an OPTIONAL attribute sy...' RFC 2119 keyword, line 65: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 203: '...ction) each collection value MUST be a...' RFC 2119 keyword, line 205: '... MUST have the same member attribute...' RFC 2119 keyword, line 213: '...member attribute MUST be unique for a ...' (50 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 325 has weird spacing: '..."1setOf type2...' == Line 385 has weird spacing: '..."1setOf type2...' == Line 524 has weird spacing: '...te name attri...' == Line 544 has weird spacing: '... If the c...' == Line 554 has weird spacing: '...tribute att...' == (74 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 (January 24, 2001) is 8492 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 24, but not defined == Missing Reference: 'IPP-IIG' is mentioned on line 56, but not defined == Missing Reference: 'RFC2119' is mentioned on line 250, but not defined ** Obsolete normative reference: RFC 2565 (Obsoleted by RFC 2910) ** Obsolete normative reference: RFC 2566 (Obsoleted by RFC 2911) ** Downref: Normative reference to an Experimental RFC: RFC 2567 ** Downref: Normative reference to an Experimental RFC: RFC 2568 ** Downref: Normative reference to an Experimental RFC: RFC 2569 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-06) exists of draft-ietf-ipp-protocol-v11-05 ** Obsolete normative reference: RFC 2911 (Obsoleted by RFC 8011) Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Roger deBry 3 Utah Valley State College 4 T. Hastings 5 Xerox Corporation 6 R. Herriot 7 Xerox Corporation 8 K. Ocke 9 Xerox Corporation 10 P. Zehler 11 Xerox Corporation 12 January 24, 2001 14 Internet Printing Protocol (IPP): 15 The 'collection' attribute syntax 16 Copyright (C) The Internet Society (2001). All Rights Reserved. 18 Status of this Memo: 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 21 working documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed as 34 http://www.ietf.org/shadow.html. 36 Abstract 37 This document specifies an OPTIONAL attribute syntax called 38 'collection' for use with the Internet Printing Protocol/1.0 39 (IPP) [RFC2565, RFC2566], IPP/1.1 [RFC2911, RFC2910], and 40 subsequent versions. A 'collection' is a container holding one or 41 more named values, which are called "member" attributes. A 42 collection allows data to be grouped like a PostScript dictionary 43 or a Java Map. This document also specifies the conformance 44 requirements for a definition document that defines a collection 45 attribute. Finally, this document gives some illustrative 46 example collection attribute definitions that are not intended as 47 actual attribute specifications. 49 The full set of IPP documents includes: 51 Design Goals for an Internet Printing Protocol [RFC2567] 52 Rationale for the Structure and Model and Protocol for the Internet 53 Printing Protocol [RFC2568] 54 Internet Printing Protocol/1.1: Model and Semantics [RFC2911] 55 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] 56 Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG] 57 Mapping between LPD and IPP Protocols [RFC2569] 59 The "Design Goals for an Internet Printing Protocol" document takes a 60 broad look at distributed printing functionality, and it enumerates 61 real-life scenarios that help to clarify the features that need to be 62 included in a printing protocol for the Internet. It identifies 63 requirements for three types of users: end users, operators, and 64 administrators. It calls out a subset of end user requirements that 65 are satisfied in IPP/1.0. A few OPTIONAL operator operations have 66 been added to IPP/1.1. 68 The "Rationale for the Structure and Model and Protocol for the 69 Internet Printing Protocol" document describes IPP from a high level 70 view, defines a roadmap for the various documents that form the suite 71 of IPP specification documents, and gives background and rationale 72 for the IETF working group's major decisions. 74 The "Internet Printing Protocol/1.1: Encoding and Transport" document 75 is a formal mapping of the abstract operations and attributes defined 76 in the model document onto HTTP/1.1 [RFC2616]. It defines the 77 encoding rules for a new Internet MIME media type called 78 "application/ipp". This document also defines the rules for 79 transporting over HTTP a message body whose Content-Type is 80 "application/ipp". This document defines a new scheme named 'ipp' 81 for identifying IPP printers and jobs. 83 The "Internet Printing Protocol/1.1: Implementer's Guide" document 84 gives insight and advice to implementers of IPP clients and IPP 85 objects. It is intended to help them understand IPP/1.1 and some of 86 the considerations that may assist them in the design of their client 87 and/or IPP object implementations. For example, a typical order of 88 processing requests is given, including error checking. Motivation 89 for some of the specification decisions is also included. 91 The "Mapping between LPD and IPP Protocols" document gives some 92 advice to implementers of gateways between IPP and LPD (Line Printer 93 Daemon) implementations. 95 Table of Contents 97 1 Introduction....................................................5 98 1.1 Problem Statement ............................................5 99 1.2 Solution .....................................................5 101 2 Terminology.....................................................6 102 2.1 Conformance Terminology ......................................6 103 2.2 Other terminology ............................................7 105 3 Definition of a Collection Attribute............................7 106 3.1 Information to Include .......................................7 107 3.2 Nested Collections ..........................................11 109 4 Collection Attributes as Attributes in Operations..............11 110 4.1 General Rules ...............................................11 111 4.2 Unsupported Values ..........................................11 113 5 Example definition of a collection attribute...................12 114 5.1 media-col (collection) ......................................12 115 5.1.1media-color (type3 keyword | name(MAX) ......................13 116 5.1.2media-size (collection) .....................................13 117 5.2 media-col-default (collection) ..............................14 118 5.3 media-col-ready (1setOf collection) .........................14 119 5.4 media-col-supported (1setOf type2 keyword) ..................14 121 6 A Second Example Definition Of A Collection Attribute..........15 123 7 Encoding.......................................................15 124 7.1 Additional tags defined for representing a collection attribute 125 value16 126 7.2 Example encoding: "media-col" (collection) ..................17 128 8 Legacy issues..................................................23 130 9 IANA Considerations............................................23 131 9.1 Attribute Syntax Registration ...............................23 133 10 Internationalization Considerations............................23 135 11 Security Considerations........................................24 137 12 References.....................................................24 139 13 Author's Addresses.............................................25 141 14 Appendix A: Encoding Example of a Simple Collection............26 142 15 Appendix B: Encoding Example of 1setOf Collection..............29 144 16 Appendix C: Encoding Example of Collection containing 1setOf XXX 145 attribute.........................................................34 147 17 Appendix D: Full Copyright Statement...........................38 149 Table of Tables 151 Table 1 - "media-col" member attributes...........................13 152 Table 2 - "media-size" collection member attributes...............13 153 Table 3 - Tags defined for encoding the 'collection' attribute syntax 154 ..............................................................16 155 Table 4 - Overview Encoding of "media-col" collection.............18 156 Table 5 - Example Encoding of "media-col" collection..............18 157 Table 6 - Overview Encoding of simple collection..................26 158 Table 7 - Example Encoding of simple collection...................26 159 Table 8 - Overview Encoding of 1setOf collection..................29 160 Table 9 - Example Encoding of 1setOf collection...................30 161 Table 10 - Overview Encoding of collection with 1setOf value......34 162 Table 11 - Example Encoding of collection with 1setOf value.......35 164 1 Introduction 166 1.1 Problem Statement 168 The IPP Model and Semantics [RFC2911] supports most of the common 169 data structures that are available in programming languages. It lacks 170 a mechanism for grouping several attributes of different types. The 171 Java language uses the Map to solve this problem and PostScript has a 172 dictionary. The new mechanism for grouping attributes together 173 (called 'collection' mechanism) must allow for optional members and 174 subsequent addition of new members. 176 The 'collection' mechanism must be encoded in a manner consistent 177 with existing 1.0 and 1.1 parsing rules (see [RFC2910]). Current 1.0 178 and 1.1 parsers that don't support the 'collection' mechanism must 179 not confuse collections or parts of collection they receive with 180 other attributes. 182 1.2 Solution 184 The new mechanism is a new IPP attribute syntax called a 185 'collection'. As such, each collection value is a value of an 186 attribute whose attribute syntax type is defined to be a 187 'collection'. Such an attribute is called a collection attribute. 188 The name of the collection attribute serves to identify the 189 collection value in an operation request or response, as with any 190 attribute value. 192 The 'collection' attribute syntax is a container holding one or more 193 named values (i.e., attributes), which are called member attributes. 194 Each collection attribute definition document lists the mandatory and 195 optional member attributes of each collection value. A collection 196 value is similar to an IPP attribute group in a request or a 197 response, such as the operation attributes group. They both consist 198 of a set of attributes. 200 As with any attribute syntax, the document that defines a collection 201 attribute specifies whether the attribute is single-value 202 (collection) or multi-valued (1setOf collection). If the attribute is 203 multi-valued (1setOf collection) each collection value MUST be a 204 separate instance of a single definition of a collection, i.e. it 205 MUST have the same member attributes except for OPTIONAL member 206 attributes. If we view each collection definition as a separate 207 syntax type, this rule continues the IPP/1.1 notion that each 208 attribute has a single type or pattern (e.g. "keyword | name" is a 209 pattern). Without this rule, the supported values would be more 210 difficult to describe and the mechanism defined in item 4 of section 211 3.1 would not be sufficient. 213 The name of each member attribute MUST be unique for a collection 214 attribute, but MAY be the same as the name of a member attribute in 215 another collection attribute and/or MAY be the same as the name of an 216 attribute that is not a member of a collection. The rules for naming 217 member attributes are given in section 3.1. 219 Each member attribute can have any attribute syntax type, including 220 'collection', and can be either single-valued or multi-valued. The 221 length of a collection value is not limited. However, the length of 222 each member attribute MUST NOT exceed the limit of its attribute 223 syntax. 225 The member attributes in a collection MAY be in any order in a 226 request or response. When a client sends a collection attribute to 227 the Printer, the order that the Printer stores the member attributes 228 of the collection value and the order returned in a response MAY be 229 different from the order sent by the client. 231 A collection value MUST NOT contains two or more member attributes 232 with the same attribute name. Such a collection is mal-formed. 233 Clients MUST NOT submit such malformed requests and Printers MUST NOT 234 return such malformed responses. If such a malformed request is 235 submitted to a Printer, the Printer MUST (depending on 236 implementation) either (1) reject the request with the 'client-error- 237 bad-request' status code (see section 13.1.4.1), or (2) accept the 238 request and use only one of each duplicate member attribute. 240 2 Terminology 242 This section defines terminology used throughout this document. 244 2.1 Conformance Terminology 246 Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD 247 NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to 248 conformance. These terms are defined in [RFC2911] section 12.1 on 249 conformance terminology, most of which is taken from RFC 2119 250 [RFC2119]. 252 The following specialization of these terms apply to this document: 254 REQUIRED: if an implementation supports the extensions described in 255 this document, it MUST support a REQUIRED feature. 257 OPTIONAL: if an implementation supports the extensions described in 258 this document, it MAY support an OPTIONAL feature. 260 2.2 Other terminology 262 This document uses terms such as Job object (or Job), IPP Printer 263 object (or Printer), "operation", "request", response", "attributes", 264 "keywords", and "support". These terms have special meaning and are 265 defined in the model terminology [RFC2911] section 12.2. The 266 following additional terms are introduced in this document: 268 collection: an attribute syntax in which each attribute value is a 269 set of attributes, called member attributes. 271 member attribute: an attribute that is defined to be used as one 272 of the attributes in a collection. 274 collection attribute: an attribute whose definition specifies the 275 'collection' attribute syntax and each of the member attributes 276 that MAY occur in a collection attribute value. 278 3 Definition of a Collection Attribute 280 This section describes the requirements for any collection attribute 281 definition. 283 3.1 Information to Include 285 When a specification document defines an "xxx" collection attribute, 286 i.e., an attribute whose attribute syntax type is 'collection' or 287 '1setOf collection'; the definition document MUST include the 288 following aspects of the attribute semantics. Suppose the "xxx" 289 collection attribute contains N member attributes named "aaa1", 290 "aaa2", _, "aaaN" ("aaaI" represents any one of these N member 291 attributes). 293 1. The name of the collection attribute MUST be specified (e.g. 294 "xxx"). The selection of the name "xxx" MUST follow the same rules 295 for uniqueness as for attributes of any other syntax type (as 296 defined by IPP/1.1) unless "xxx" is a member attribute of another 297 collection. Then the selection of the name "xxx" MUST follow the 298 rules for uniqueness defined in item 5a) of this list. 300 2. The collection attribute syntax MUST be of type 'collection' or 301 '1setOf collection'. 303 3. The context of the collection attribute MUST be specified, i.e., 304 whether the attribute is an operation attribute, a Job Template 305 attribute, a Job Description attribute, a Printer Description 306 attribute, a member attribute of a particular collection attribute, 307 etc. 309 4. An "xxx-supported" attribute MUST be specified and it has one of 310 the following two forms: 312 a)"xxx-supported" is a "1setOf collection" which enumerates all of 313 the supported collection values of "xxx". If a collection of 314 this form contains a nested collection, it MUST be of the same 315 form. 317 For example, "media-size-supported" might have the values {{x- 318 dimension:210, y-dimension:297},{x-dimension:297, y- 319 dimension:420}} to show that it supports two values of "media 320 size": A4 (210x297) and A3 (297x420). It does not support other 321 combinations of "x-dimension" and "y-dimension" member 322 attributes, such as 210x420 or 297x297 and it does not supported 323 non-enumerated values, such as 420x595. 325 b)"xxx-supported" is a "1setOf type2 keyword" which enumerates 326 the names of all of the member attributes of "xxx": "aaa1", 327 "aaa2", _, "aaaN". If a collection of this form contains a 328 nested collection, it MAY be of either form. See item 5f) below 329 for details on supported values of member attributes. 331 For example, "media-col-supported" might have the keyword 332 values: "media-size" and "media-color". 334 5. The member attributes MUST be defined. For each member attribute 335 the definition document MUST provide the following information: 337 a)The member attribute's name (e.g., "aaa") MUST be unique within 338 the collection being defined and MUST either 340 i) reuse the attribute name of another attribute (that is unique 341 across the entire IPP attribute name space) and have the same 342 syntax and semantics as the reused attribute (if the condition 343 of item 4b) above is met). For example, a member attribute 344 definition could reuse the IPP/1.1 "media" attribute. 346 ii) potentially occur elsewhere in the entire IPP attribute 347 name space. (if the condition of item 4a) above is met). For 348 example, a member attribute could be "x-dimension" which could 349 potentially occur in another collection or as an attribute 350 outside of a collection. 352 iii) be unique across the entire IPP attribute name space (if 353 the condition of item 4b) above is met). For example, a member 354 attribute could be "media-color" which must unique be across 355 the entire IPP attribute name space. 357 b)Whether the member attribute is REQUIRED or OPTIONAL for the 358 Printer to support 360 c)Whether the member attribute is REQUIRED or OPTIONAL for the 361 client to supply in a request 363 d)The member attribute's syntax type, which can be any attribute 364 syntax, including '1setOf X', 'collection', and '1setOf 365 collection'. If this attribute name reuses the name of another 366 attribute (case of item a1 above), it MUST have the same 367 attribute syntax, including cardinality (whether or not 1setOf). 369 e)The semantics of the "aaa" member attribute. The semantic 370 definition MUST include a description of any constraint or 371 boundary conditions the member attribute places on the 372 associated attribute, especially if the attribute reuses the 373 name of another attribute (case of item a1 above) 375 f)The supported values for the each "aaaI" member attribute (of 376 the member attributes "aaa1", "aaa2", _, "aaaN") is specified 377 by one of two mechanisms. 379 i) If "xxx-supported" is a "1setOf collection" (see item 4a) 380 above), the value for each "aaaI" is specified in each 381 collection value of "xxx-supported" in the context of other 382 member attributes. That is, "xxx-supported" enumerates all 383 supported values of "xxx". 385 ii) If the value of "xxx-supported" is a "1setOf type2 386 keyword" (see item 4b) above), the supported values of "aaaI" 387 are the values specified by either i) the "aaaI-supported" 388 attribute or ii) the definition of the member attribute "aaaI" 389 within the document defining the "xxx" attribute. The values 390 of each member attribute "aaaI" are specified independently of 391 other member attributes though a Printer is not required to 392 support all combinations of supported values. 394 For example, "media-col-supported" might have the keyword 395 values: "media-size" and "media-color". Using the first method 396 for defining supported values (an "aaaI-supported" attribute), 397 the collection values of "media-col" are combinations of 398 values of "media-size-supported" and "media-color- 399 supported".If "media-size-supported" has the values of 400 '210x297' and '297x420' and "media-color-supported" has the 401 values of 'white' and 'pink', the Printer might support only 402 the combinations 'white-210x297', 'pink-210x297'and 'white- 403 297x420', and not 'pink-297x420'. 405 If a collection contains a member "aaaI" whose syntax type is 406 "text", the supported values would probably be defined by the 407 definition of "xxx" rather than by the attribute "aaaI- 408 supported". 410 g)the default value of each "aaaI" member attribute if it is 411 OPTIONAL for a client to supply the "aaa" member attribute in a 412 request. The default value is specified by in the attribute's 413 definition within a document and MUST be one of the following: 415 i) a fixed default 417 ii) a mechanism by which the Printer determines default 419 iii) an indefinite default that is left to the implementation. 421 iv) an attribute that the Printer uses to determine the default 423 6. The default value of "xxx" if a client does not supply it. The 424 default value is specified by in the attribute's definition within 425 a document and MUST be one of the following: 427 a)a fixed default 429 b)a mechanism by which the Printer determines default 431 c)an indefinite default that is left to the implementation 433 d)a Printer attribute "xxx-default" which is a collection with the 434 same member attributes as "xxx". Though optional member 435 attributes may be absent in which case the Printer uses the 436 defaulting rules of item 5g) above. 438 7. The "xxx-ready (1setOf collection)" attribute if human intervention 439 is required to make many of the supported values available. For 440 example, "media-col" is an attribute which has a "ready" attribute. 441 Most attributes do not have a "ready" attribute. 443 3.2 Nested Collections 445 A member attribute may have a syntax type of 'collection' or '1setOf 446 collection', in which case it is called a nested collection 447 attribute. The rules for a nested collection attribute are the same 448 as for a collection attribute as specified in section 3.1. 450 4 Collection Attributes as Attributes in Operations 452 4.1 General Rules 454 A collection value is like any other IPP/1.1 value, except that it is 455 structured. The rules for attributes with collection values are the 456 same as for attributes of any other syntax type (see IPP/1.1), be 457 they in any group of a request of a response. 459 4.2 Unsupported Values 461 The rules for returning an unsupported collection attribute are an 462 extension to the current rules: 464 1. If the entire collection attribute is unsupported, then the 465 Printer returns just the collection attribute name with the 466 'unsupported' out-of-band value (see the beginning of [RFC2911] 467 section 4.1) in the Unsupported Attributes Group. 469 2. If a collection contains unrecognized, unsupported member 470 attributes and/or conflicting values, the attribute returned in 471 the Unsupported Group is a collection containing the 472 unrecognized, unsupported member attributes, and/or conflicting 473 values. The unrecognized member attributes have an out-of-band 474 value of 'unsupported' (see the beginning of [RFC2911] section 475 4.1). The unsupported member attributes and conflicting values 476 have their unsupported or conflicting values. 478 5 Example definition of a collection attribute 480 In some printing environments, it is desirable to allow the client to 481 select the media by its properties, e.g., weight, color, size, etc., 482 instead of by name. In IPP/1.1 (see [RFC2911]), the "media (type3 483 keyword | name) Job Template attribute allows selection by name. It 484 is tempting to extend the "media" attribute syntax to include 485 "collection", but then existing clients could not understand default 486 or supported media values that use the collection value. To preserve 487 interoperability, a new attribute MUST BE added, e.g., "media-col 488 (collection)". The following subsections contain a sample definition 489 of a simplified "media-col" attribute. The definition follows the 490 rules in section 3. 492 All of the example attribute definitions in this document are 493 illustrative examples, rather than actual definitions. These 494 examples are intended to illustrate how to define collection 495 attributes. Other documents MUST define collection attributes for 496 use in actual interchange. Such definitions may be very similar to 497 the examples in this document, since we attempted to pick useful 498 examples. 500 Note: we picked the name "media-col" because the name "media" is 501 already in use. Ordinarily the collection attribute would have a name 502 like any other attribute and would not end in "col". 504 The member attributes of "media-col" attribute ("media-color (type 3 505 keyword)" and "media-size (collection)") both follow the naming rules 506 of item 4a3 of section 3, i.e. the names are unique across the entire 507 IPP attribute name space. The member attributes of the "media-size 508 (collection)" member attribute ("x-dimension (integer(0,MAX))" and 509 "y-dimension (integer(0,MAX))") both follow the naming rules of item 510 4a2 of section 3, i.e. they potentially occur elsewhere in the IPP 511 attribute name space. 513 5.1 media-col (collection) 515 The "media-col" (collection) attribute augments the IPP/1.1 [RFC2911] 516 "media" attribute. This collection attribute enables a client end 517 user to submit a list of media characteristics to the Printer. When 518 the client specifies media using the "media-col" collection 519 attribute, the Printer object MUST match the requested media exactly. 520 The 'collection' consists of the following member attributes: 522 Table 1 - "media-col" member attributes 524 Attribute name attribute syntax reque Printer 525 st Support 527 media-color type3 keyword | name (MAX) MAY MUST 529 media-size collection MUST MUST 531 The definitions for the member attributes is given in the following 532 sub-sections: 534 5.1.1 media-color (type3 keyword | name(MAX) 536 This member attribute identifies the color of the media. Valid 537 values are 'red', 'white' and 'blue' 539 The "media-color-supported" (1setOf (type3 keyword | name(MAX))) 540 Printer attribute identifies the values of this "media-color" 541 member attribute that the Printer supports, i.e., the colors 542 supported. 544 If the client omits this member attribute, the Printer determines 545 the value in an implementation dependent manner. 547 5.1.2 media-size (collection) 549 This member attribute identifies the size of the media. The 550 'collection' consists of the member attributes shown in Table 2: 552 Table 2 - "media-size" collection member attributes 554 Attribute attribute syntax request Printer 555 name Support 557 x-dimension integer (0:MAX) MUST MUST 559 y-dimension integer (0:MAX) MUST MUST 560 The definitions for the member attributes is given in the 561 following sub-sections: 563 5.1.2.1 x-dimension (integer(0:MAX)) 564 This attribute identifies the width of the media in inch units 565 along the X axis. 567 5.1.2.2 y-dimension (integer(0:MAX)) 568 This attribute identifies the height of the media in inch 569 units along the Y axis. 571 The "media-size-supported" (1setOf collection) Printer 572 attribute identifies the values of this "media-size" member 573 attribute that the Printer supports, i.e., the size 574 combinations supported. The names of the member attributes 575 are the same as the member attributes of the "media-size" 576 collection attribute, namely "x-dimension", and "y-dimension", 577 since they have the same attribute syntax and the same 578 semantics. 580 5.2 media-col-default (collection) 582 The "media-col-default" Printer attribute specifies the media that 583 the Printer uses, if any, if the client omits the "media-col" and 584 "media". Job Template attribute in the Job Creation operation (and 585 the PDL doesn't include a media specification). The member 586 attributes are defined in Table 1. A Printer MUST support the same 587 member attributes for this default collection attribute as it 588 supports for the corresponding "media-col" Job Template attribute. 590 5.3 media-col-ready (1setOf collection) 592 The "media-col-ready" Printer attribute identifies the media that are 593 available for use without human intervention, i.e., the media that 594 are ready to be used without human intervention. The collection 595 value MUST have all of the member attributes that are supported in 596 Table 1. 598 5.4 media-col-supported (1setOf type2 keyword) 600 The "media-col-supported" Printer attribute identifies the keyword 601 names of the member attributes supported in the "media-col" 602 collection Job Template attribute, i.e., the keyword names of the 603 member attributes in Table 1 that the Printer supports. 605 6 A Second Example Definition Of A Collection Attribute 607 All of the example attribute definitions in this document are 608 illustrative examples, rather than actual definitions. These 609 examples are intended to illustrate how to define collection 610 attributes. Other documents MUST define collection attributes for 611 use in actual interchange. Such definitions may be very similar to 612 the examples in this document, since we attempted to pick useful 613 examples. 615 In some printing environments, it is desirable to allow the client to 616 select the media for the job start sheet. The reason for not adding 617 the 'collection' attribute syntax to the existing "job-sheets" Job 618 Template attribute is the same as for "media". Instead, a new Job 619 Template attribute is introduced, e.g. "job-sheet-col (collection)". 621 The member attributes of "job-sheet-col" attribute ("job-sheets 622 (type 3 keyword)" and "media (type3 keyword | name)") both follow 623 the naming rules of item 4a1 of section 3, i.e they reuse existing 624 IPP attributes. According to the rules, their supported values come 625 from the existing IPP attributes: "job-sheets-supported" and "media- 626 supported". However, their default values do not come from "job- 627 sheets-default" and "media-default", respectively. Rather the 628 definition of "job-sheet-col" says that "job-sheets (type 3 keyword)" 629 is required and if "media (type3 keyword | name)" is absent, the 630 Printer uses the same media as the rest of the job uses. 632 If "job-sheet-col" attribute were defined to contain the member 633 attribute "job-sheet-media (type3 keyword | name)" instead of "media 634 (type3 keyword | name)", then the definition would also have to 635 specify a "job-sheet-media-supported (1setOf (type3 keyword | 636 name))" whose values would be independent of "media-supported 637 (1setOf (type3 keyword | name))" and would be set separately by a 638 System Administrator. 640 The actual text for the definition of the attribute is left as an 641 exercise for the reader. 643 7 Encoding 645 This section defines the additional encoding tags used according to 646 [RFC2910] and gives an example of their use. The encoding tags 647 define in this document MUST be used by all collection attributes 648 defined in other documents. However, the example of their use is 649 illustrative only. 651 7.1 Additional tags defined for representing a collection attribute 652 value 654 The 'collection' attribute syntax uses the tags defined in Table 3. 656 Table 3 - Tags defined for encoding the 'collection' attribute syntax 658 Tag name Tag Meaning 659 value 661 begCollection 0x34 Begin the collection attribute value. 663 endCollection 0x37 End the collection attribute value. 665 memberAttrName 0x4A The value is the name of the 666 collection member attribute 668 When encoding a collection attribute "xxx" that contains an attribute 669 "aaa" and is not inside another collection, the encoding follows 670 these rules: 672 1. The beginning of the collection is indicated with a value tag 673 that MUST be syntax type 'begCollection' (0x34) with a name 674 length and Name field that represent the name of the collection 675 attribute ("xxx") as with any attribute, followed by a value. The 676 Printer MAY ignore the value and its length of MAY be 0. In the 677 future, however, this field MAY contain useful information, such 678 as the collection name (cf. the name of a C struct). 680 2. Each member attribute is encoded as a sequence of two or more 681 values that appear to be part of a single multi-valued attribute, 682 i.e. 1setOf. The first value after the 'begCollection' value has 683 the attribute syntax 'memberAttrName' (0x4A) and its value holds 684 the name of the first member attribute (e.g. "aaa"). The second 685 value holds the first member's attribute value, which can be of 686 any attribute syntax, except 'memberAttrName' or 'endCollection'. 687 If the first member's attribute value is multi-valued, the third 688 value holds the second value of the first member's value. 689 Otherwise, the third value holds the name of second member 690 attribute (e.g. "bbb") and its attribute syntax is 691 'memberAttrName'. In this case, the fourth member's value is the 692 value of "bbb". 694 Note that the technique of encoding a 'collection' as a '1setOf' 695 makes it easy for a Printer that doesn't support a particular 696 collection attribute (or the collection attribute syntax at all) 697 to simply skip over the entire collection value. 699 3. The end of the collection is indicated with a value tag that MUST 700 be syntax type 'endCollection' (e.g. 0x37) and MAY have a zero 701 name length and a zero value length. In the future, this field 702 MAY contain useful information,such as the collection name that 703 matches the one in the 'begCollection' . 705 4. It is valid to have a member attribute that is, itself, a 706 collection attribute, i.e., collections can be nested within 707 collections. This is represented by the occurrence of a member 708 attribute that is of attribute syntax type 'begCollection'. Such 709 a collection is terminated by a matching 'endCollection'. The 710 name of such a member attribute is in the immediately preceding 711 value whose syntax type is 'memberAttrName'. 713 5. It is valid for a collection attribute to be multi-valued, i.e., 714 have more than one collection value. If the next attribute 715 immediately following the 'endCollection' has a zero name length 716 and a tag of 'begCollection', then the collection attribute is a 717 multi-valued collection, as with any attribute. This statement 718 applies to collections within collections and collections that 719 are not in collections. 721 7.2 Example encoding: "media-col" (collection) 723 The collection specified in section 5 is used for the encoding 724 example shown in Table 5. The example also shows nested collections, 725 since the "media-size" member attribute is a 'collection. The 726 encoding example represents a blue 4x6-index cards and takes 216 727 octets. The Appendices contains more complex examples. 729 Additional examples have been included in the appendices. 731 The overall structure of the two collection values can be pictorially 732 represented as: 734 "media-col" = 735 { "media-color" = 'blue'; 736 "media-size" = 737 { "x-dimension" = 6; 738 "y-dimension" = 4 739 } 740 }, 742 The full encoding is in table 4. A simplified view of the encoding 743 looks like this: 745 Table 4 - Overview Encoding of "media-col" collection 747 Tag Value Name Value 749 begCollection media-col "" 751 memberAttrName "" media-color 753 keyword "" blue 755 memberAttrName "" media-size 757 begCollection "" "" 759 memberAttrName "" x-dimension 761 integer "" 6 763 memberAttrName "" y-dimension 765 integer "" 4 767 endCollection "" "" 769 endCollection "" "" 771 Table 5 - Example Encoding of "media-col" collection 773 Octets Symbolic Value Protocol comments 774 field 776 0x34 begCollection value-tag beginning of the "media- 777 col" collection attribute 779 0x0009 name- length of (collection) 780 length attribute name 782 Octets Symbolic Value Protocol comments 783 field 785 media-col media-col name name of (collection) 786 attribute 788 0x0000 value- defined to be 0 for this 789 length type 791 no value (since value- 792 length was 0) 794 0x4A memberAttrName value-tag starts a new member 795 attribute: "media-color" 797 0x0000 name- defined to be 0 for this 798 length type, so part of 1setOf 800 no name (since name-length 801 was 0) 803 0x000B value- length of "media-color" 804 length keyword 806 media-color media-color value value is name of 1st 807 member attribute 809 0x44 keyword type value-tag keyword type 811 0x0000 name- 0 indicates 1setOf 812 length 814 no name (since name-length 815 was 0) 817 0x0004 value- 818 length 820 blue blue value value of 1st member 821 attribute 823 0x4A memberAttrName value-tag starts a new member 824 attribute: "media-size" 826 Octets Symbolic Value Protocol comments 827 field 829 0x0000 name- defined to be 0 for this 830 length type, so part of 1setOf 832 no name (since name-length 833 was 0) 835 0x000A value- length of "media-size" 836 length keyword 838 media-size media-size value Name of 2nd member 839 attribute 841 0x34 begCollection value-tag Beginning of the "media- 842 size" collection attribute 843 which is a sub-collection 845 0x0000 name- 0 indicates 1setOf 846 length 848 no name (since name-length 849 was 0) 851 0x0000 value- collection attribute names 852 length have no value 854 no value (since value- 855 length was 0) 857 0x4A memberAttrName value-tag starts a new member 858 attribute: "x-dimension" 860 0x0000 name- defined to be 0 for this 861 length type, so part of 1setOf 863 no name (since name-length 864 was 0) 866 0x000B value- length of "x-dimension" 867 length keyword 869 Octets Symbolic Value Protocol comments 870 field 872 x-dimension x-dimension value name of 1st sub- 873 collection member 874 attribute 876 0x21 integer type value-tag attribute type 878 0x0000 name- 0 indicates 1setOf 879 length 881 no name (since name-length 882 was 0) 884 0x0004 value- length of an integer = 4 885 length 887 0x0006 value value of 1st sub- 888 collection member 889 attribute 891 0x4A memberAttrName value-tag starts a new member 892 attribute: "y-dimension" 894 0x0000 name- defined to be 0 for this 895 length type, so part of 1setOf 897 no name (since name-length 898 was 0) 900 0x000B value- length of the "y- 901 length dimension" keyword 903 y-dimension y-dimension value name of 2nd sub- 904 collection member 905 attribute 907 0x21 integer type value-tag attribute type 909 0x0000 name- 0 indicates 1setOf 910 length 912 Octets Symbolic Value Protocol comments 913 field 915 no name (since name-length 916 was 0) 918 0x0004 value- length of an integer = 4 919 length 921 0x0004 value value of 2nd sub- 922 collection member 923 attribute 925 0x37 endCollection value-tag end of the sub-collection 927 0x0000 name- defined to be 0 for this 928 length type, so part of 1setOf 930 no name (since name-length 931 was 0) 933 0x0000 value- defined to be 0 for this 934 length type 936 no value (since value- 937 length was 0) 939 0x37 endCollection value-tag end of the 1st collection 940 value in 1setOf 942 0x0000 name- defined to be 0 for this 943 length type, so part of 1setOf 945 no name (since name-length 946 was 0) 948 0x0000 value- defined to be 0 for this 949 length type 951 no value (since value- 952 length was 0) 954 8 Legacy issues 956 IPP 1.x Printers and Clients will gracefully ignore collections and 957 its member attributes if it does not understand the collection. The 958 begCollection and endCollection elements each look like an attribute 959 with an attribute syntax that the recipient doesn't support and so 960 should ignore the entire attribute. The individual member attributes 961 and their values will look like a 1setOf values of the collection 962 attribute, so that the Printer simply ignores the entire attribute 963 and all of its values. Returning unsupported attributes is also 964 simple, since only the name of the collection attribute is returned 965 with the 'unsupported' out-of-band value (see section 4.2). 967 9 IANA Considerations 969 This section contains the exact information for IANA to add to the 970 IPP Registries according to the procedures defined in "IPP/1.1 Model 971 and Semantics" document [RFC2911] section 6. 973 Note to RFC Editors: Replace RFC NNNN below with the RFC number for 974 this document, so that it accurately reflects the content of the 975 information for the IANA Registry. 977 9.1 Attribute Syntax Registration 979 The attribute syntax defined in this document will be published by 980 IANA according to the procedures in RFC 2911 [RFC2911] section 6.3 981 with the following path: 983 ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/ 985 The registry entry will contain the following information: 987 Reference: 988 RFC NNNN [this document] 990 Attribute Syntaxes: Ref. Section: 991 collection RFC NNNN 3 993 10 Internationalization Considerations 995 This attribute syntax by itself has no impact on 996 internationalization. However, the member attributes that are 997 subsequently defined for use in a collection may have 998 internationalization considerations, as may any attribute, according 999 to [RFC2911]. 1001 11 Security Considerations 1003 This attribute syntax causes no more security concerns than any other 1004 attribute syntax. It is only the attributes that are subsequently 1005 defined to use this or any other attribute syntax that may have 1006 security concerns, depending on the semantics of the attribute, 1007 according to [RFC2911]. 1009 12 References 1011 [ipp-ntfy] 1012 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 1013 Bergman, R. " Internet Printing Protocol/1.0 & 1.1: IPP Event 1014 Notification Specification" draft-ietf-ipp-not-spec-02.txt, work in 1015 progress, February 2, 2000. 1017 [RFC2565] 1018 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 1019 Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. 1021 [RFC2566] 1022 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1023 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 1024 April 1999. 1026 [RFC2567] 1027 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 1028 2567, April 1999. 1030 [RFC2568] 1031 Zilles, S., "Rationale for the Structure and Model and Protocol for 1032 the Internet Printing Protocol", RFC 2568, April 1999. 1034 [RFC2569] 1035 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 1036 LPD and IPP Protocols", RFC 2569, April 1999. 1038 [RFC2616] 1039 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1040 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1041 RFC 2616, June 1999. 1043 [RFC2910] 1044 Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing 1045 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 1046 05.txt, March 1, 2000. 1048 [RFC2911] 1049 Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P., 1050 "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, 1051 September 2000. 1053 13 Author's Addresses 1055 Roger deBry 1056 Utah Valley State College 1057 Orem, UT 84058 1058 Phone: (801) 222-8000 1059 EMail: debryro@uvsc.edu 1061 Tom Hastings 1062 Xerox Corporation 1063 737 Hawaii St. ESAE 231 1064 El Segundo, CA 90245 1065 Phone: 310-333-6413 1066 Fax: 310-333-5514 1067 e-mail: hastings@cp10.es.xerox.com 1069 Robert Herriot 1070 Xerox Corp. 1071 3400 Hill View Ave, Building 1 1072 Palo Alto, CA 94304 1073 Phone: 650-813-7696 1074 Fax: 650-813-6860 1075 e-mail: robert.herriot@pahv.xerox.com 1077 Kirk Ocke 1078 Xerox Corp. 1079 800 Phillips Rd 1080 M/S 139-05A 1081 Webster, NY 14580 1082 Phone: (716) 442-4832 1083 EMail: kirk.ocke@usa.xerox.com 1085 Peter Zehler 1086 Xerox Corp. 1087 800 Phillips Rd 1088 M/S 139-05A 1089 Webster, NY 14580 1090 Phone: (716) 265-8755 1091 EMail: peter.zehler@usa.xerox.com 1093 14 Appendix A: Encoding Example of a Simple Collection 1095 The overall structure of the collection value can be pictorially 1096 represented as: 1098 " media-size " = 1099 { "x-dimension" = 6; 1100 "y-dimension" = 4 1101 } 1103 A simplified view of the encoding would look like this: 1105 Table 6 - Overview Encoding of simple collection 1107 Tag Value Name Value 1109 begCollection media-size "" 1111 memberAttrName "" x-dimension 1113 integer "" 6 1115 memberAttrName "" y-dimension 1117 integer "" 4 1119 endCollection "" "" 1121 Note: "" represents a name or value whose length is 0. 1123 Table 7 - Example Encoding of simple collection 1125 Octets Symbolic Value Protocol comments 1126 field 1128 0x34 begCollection value-tag beginning of the "media- 1129 size" collection attribute 1131 Octets Symbolic Value Protocol comments 1132 field 1134 0x000A name- length of (collection) 1135 length attribute name 1137 media-size media-size name name of (collection) 1138 attribute 1140 0x0000 value- defined to be 0 for this 1141 length type 1143 no value (since value- 1144 length was 0) 1146 0x4A memberAttrName value-tag starts member attribute: 1147 "x-dimension" 1149 0x0000 name- defined to be 0 for this 1150 length type, so part of 1setOf 1152 no name (since name-length 1153 was 0) 1155 0x000B value- length of "x-dimension" 1156 length keyword 1158 x-dimension x-dimension value name of 1st collection 1159 member attribute 1161 0x21 integer type value-tag attribute type 1163 0x0000 name- 0 indicates 1setOf 1164 length 1166 no name (since name-length 1167 was 0) 1169 0x0004 value- length of an integer = 4 1170 length 1172 0x0006 value value of 1st collection 1173 member attribute 1175 Octets Symbolic Value Protocol comments 1176 field 1178 0x4A memberAttrName value-tag starts a new member 1179 attribute: "y-dimension" 1181 0x0000 name- defined to be 0 for this 1182 length type, so part of 1setOf 1184 no name (since name-length 1185 was 0) 1187 0x000B value- length of the "y- 1188 length dimension" keyword 1190 y-dimension y-dimension value name of 2nd collection 1191 member attribute 1193 0x21 integer type value-tag attribute type 1195 0x0000 name- 0 indicates 1setOf for 1196 length media-size 1198 no name (since name-length 1199 was 0) 1201 0x0004 value- length of an integer = 4 1202 length 1204 0x0004 value value of 2nd collection 1205 member attribute 1207 0x37 endCollection value-tag end of the collection 1209 0x0000 name- defined to be 0 for this 1210 length type, so part of 1setOf 1212 no name (since name-length 1213 was 0) 1215 0x0000 value- defined to be 0 for this 1216 length type 1218 Octets Symbolic Value Protocol comments 1219 field 1221 no value (since value- 1222 length was 0) 1224 15 Appendix B: Encoding Example of 1setOf Collection 1226 The overall structure of the collection value can be pictorially 1227 represented as: 1229 "media-size-supported" = 1230 { "x-dimension" = 6; 1231 "y-dimension" = 4 1232 }, 1233 { "x-dimension" = 3; 1234 "y-dimension" = 5 1235 }; 1237 A simplified view of the encoding would look like this: 1239 Table 8 - Overview Encoding of 1setOf collection 1241 Tag Value Name Value 1243 begCollection media-size- "" 1244 supported 1246 memberAttrName "" x-dimension 1248 integer "" 6 1250 memberAttrName "" y-dimension 1252 integer "" 4 1254 endCollection "" "" 1255 begCollection "" "" 1257 memberAttrName "" x-dimension 1259 integer "" 3 1261 memberAttrName "" y-dimension 1263 integer "" 5 1265 endCollection "" "" 1267 Table 9 - Example Encoding of 1setOf collection 1269 Octets Symbolic Value Protocol comments 1270 field 1272 0x34 begCollection value-tag beginning of the "media- 1273 size-supported (1setOf 1274 collection" attribute 1276 0x00014 name- length of (collection) 1277 length attribute name 1279 media-size- media-size- name name of (collection) 1280 supported supported attribute 1282 0x0000 value- defined to be 0 for this 1283 length type 1285 no value (since value- 1286 length was 0) 1288 0x4A memberAttrName value-tag starts member attribute: 1289 "x-dimension" 1291 0x0000 name- defined to be 0 for this 1292 length type, so part of 1setOf 1294 no name (since name-length 1295 was 0) 1297 Octets Symbolic Value Protocol comments 1298 field 1300 0x000B value- length of "x-dimension" 1301 length keyword 1303 x-dimension x-dimension value name of 1st collection 1304 member attribute 1306 0x21 integer type value-tag attribute type 1308 0x0000 name- 0 indicates 1setOf 1309 length 1311 no name (since name-length 1312 was 0) 1314 0x0004 value- length of an integer = 4 1315 length 1317 0x0006 value value of 1st collection 1318 member attribute 1320 0x4A memberAttrName value-tag starts member attribute: 1321 "y-dimension" 1323 0x0000 name- defined to be 0 for this 1324 length type, so part of 1setOf 1326 no name (since name-length 1327 was 0) 1329 0x000B value- length of the "y- 1330 length dimension" keyword 1332 y-dimension y-dimension value name of 2nd collection 1333 member attribute 1335 0x21 integer type value-tag attribute type 1337 0x0000 name- 0 indicates 1setOf 1338 length 1340 no name (since name-length 1341 was 0) 1343 Octets Symbolic Value Protocol comments 1344 field 1346 0x0004 value- length of an integer = 4 1347 length 1349 0x0004 value value of 2nd collection 1350 member attribute 1352 0x37 endCollection value-tag end of the collection 1354 0x0000 name- defined to be 0 for this 1355 length type, so part of 1setOf 1357 no name (since name-length 1358 was 0) 1360 0x0000 value- defined to be 0 for this 1361 length type 1363 no value (since value- 1364 length was 0) 1366 0x34 begCollection value-tag beginning of the 2nd 1367 member of the 1SetOf 1368 "sizes-avail " collection 1369 attribute 1371 0x0000 name- Zero length name indicates 1372 length this is member of previous 1373 attribute 1375 name no name (since name-length 1376 was 0) 1378 0x0000 value- defined to be 0 for this 1379 length type 1381 no value (since value- 1382 length was 0) 1384 0x4A memberAttrName value-tag starts member attribute: 1385 "x-dimension" 1387 0x0000 name- defined to be 0 for this 1388 length type, so part of 1setOf 1390 Octets Symbolic Value Protocol comments 1391 field 1393 no name (since name-length 1394 was 0) 1396 0x000B value- length of "x-dimension" 1397 length keyword 1399 x-dimension x-dimension value name of 1st collection 1400 member attribute 1402 0x21 integer type value-tag attribute type 1404 0x0000 name- 0 indicates 1setOf 1405 length 1407 no name (since name-length 1408 was 0) 1410 0x0004 value- length of an integer = 4 1411 length 1413 0x0003 value value of 1st collection 1414 member attribute 1416 0x4A memberAttrName value-tag starts member attribute: 1417 "y-dimension" 1419 0x0000 name- defined to be 0 for this 1420 length type, so part of 1setOf 1422 no name (since name-length 1423 was 0) 1425 0x000B value- length of the "y- 1426 length dimension" keyword 1428 y-dimension y-dimension value name of 2nd collection 1429 member attribute 1431 0x21 integer type value-tag attribute type 1433 0x0000 name- 0 indicates 1setOf 1434 length 1436 Octets Symbolic Value Protocol comments 1437 field 1439 no name (since name-length 1440 was 0) 1442 0x0004 value- length of an integer = 4 1443 length 1445 0x0005 value value of 2nd collection 1446 member attribute 1448 0x37 endCollection value-tag end of the 1setOf 1449 collection value 1451 0x0000 name- defined to be 0 for this 1452 length type, so part of 1setOf 1454 no name (since name-length 1455 was 0) 1457 0x0000 value- defined to be 0 for this 1458 length type 1460 no value (since value- 1461 length was 0) 1463 16 Appendix C: Encoding Example of Collection containing 1setOf XXX 1464 attribute 1466 The overall structure of the collection value can be pictorially 1467 represented as: 1469 "wagons" = 1470 { "colors" = red, blue; 1471 "sizes" = 4, 6, 8 1472 } 1474 A simplified view of the encoding would look like this: 1476 Table 10 - Overview Encoding of collection with 1setOf value 1478 Tag Value Name Value 1480 begCollection wagons "" 1482 memberAttrName "" colors 1484 keyword "" red 1486 keyword "" blue 1488 memberAttrName "" sizes 1490 integer "" 4 1492 integer "" 6 1494 integer "" 8 1496 endCollection "" "" 1498 Table 11 - Example Encoding of collection with 1setOf value 1500 Octets Symbolic Value Protocol comments 1501 field 1503 0x34 begCollection value-tag beginning of the "wagons" 1504 collection attribute 1506 0x0005 name- length of (collection) 1507 length attribute name 1509 wagons wagons name name of (collection) 1510 attribute 1512 0x0000 value- defined to be 0 for this 1513 length type 1515 no value (since value- 1516 length was 0) 1518 Octets Symbolic Value Protocol comments 1519 field 1521 0x4A memberAttrName value-tag starts a new member 1522 attribute: "colors" 1524 0x0000 name- defined to be 0 for this 1525 length type, so part of 1setOf 1527 no name (since name-length 1528 was 0) 1530 0x0006 value- length of "colors" keyword 1531 length 1533 colors colosr value value is name of 1st 1534 member attribute 1536 0x44 keyword type value-tag keyword type 1538 0x0000 name- 0 indicates 1setOf wagons 1539 length 1541 no name (since name-length 1542 was 0) 1544 0x0004 value- 1545 length 1547 blue blue value value of 1st member 1548 attribute 1550 0x44 keyword type value-tag keyword type 1552 0x0000 name- 0 indicates 1setOf wagons 1553 length 1555 no name (since name-length 1556 was 0) 1558 0x0003 value- 1559 length 1561 red red value value of 1st member 1562 attribute 1564 Octets Symbolic Value Protocol comments 1565 field 1567 0x4A memberAttrName value-tag starts a new member 1568 attribute: "sizes" 1570 0x0000 name- defined to be 0 for this 1571 length type, so part of 1setOf 1573 no name (since name-length 1574 was 0) 1576 0x0005 value- length of "length-avail" 1577 length keyword 1579 sizes sizes value Name of 2nd member 1580 attribute 1582 0x21 integer type value-tag attribute type 1584 0x0000 name- 0 indicates 1setOf wagons 1585 length 1587 no name (since name-length 1588 was 0) 1590 0x0004 value- length of an integer = 4 1591 length 1593 0x0004 value 1st value for 1SetOf 1594 integer attribute 1596 0x21 integer type value-tag attribute type 1598 0x0000 name- 0 indicates 1setOf 1599 length 1601 no name (since name-length 1602 was 0) 1604 0x0004 value- length of an integer = 4 1605 length 1607 0x0006 value 2nd value for 1SetOf 1608 integer attribute 1610 Octets Symbolic Value Protocol comments 1611 field 1613 0x21 integer type value-tag attribute type 1615 0x0000 name- 0 indicates 1setOf 1616 length 1618 no name (since name-length 1619 was 0) 1621 0x0004 value- length of an integer = 4 1622 length 1624 0x0008 value 3rd value for 1SetOf 1625 integer attribute 1627 0x37 endCollection value-tag end of the collection 1629 0x0000 name- defined to be 0 for this 1630 length type, so part of 1setOf 1632 no name (since name-length 1633 was 0) 1635 0x0000 value- defined to be 0 for this 1636 length type 1638 no value (since value- 1639 length was 0) 1641 17 Appendix D: Full Copyright Statement 1643 Copyright (C) The Internet Society (1998,1999,2000,2001). All Rights 1644 Reserved 1646 This document and translations of it may be copied and furnished to 1647 others, and derivative works that comment on or otherwise explain it 1648 or assist in its implementation may be prepared, copied, published 1649 and distributed, in whole or in part, without restriction of any 1650 kind, provided that the above copyright notice and this paragraph are 1651 included on all such copies and derivative works. However, this 1652 document itself may not be modified in any way, such as by removing 1653 the copyright notice or references to the Internet Society or other 1654 Internet organizations, except as needed for the purpose of 1655 developing Internet standards in which case the procedures for 1656 copyrights defined in the Internet Standards process must be 1657 followed, or as required to translate it into languages other than 1658 English. 1660 The limited permissions granted above are perpetual and will not be 1661 revoked by the Internet Society or its successors or assigns. 1663 This document and the information contained herein is provided on an 1664 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1665 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1666 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1667 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1668 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.