diff options
Diffstat (limited to 'doc/rfc/rfc3382.txt')
| -rw-r--r-- | doc/rfc/rfc3382.txt | 2131 |
1 files changed, 2131 insertions, 0 deletions
diff --git a/doc/rfc/rfc3382.txt b/doc/rfc/rfc3382.txt new file mode 100644 index 0000000..4181c5b --- /dev/null +++ b/doc/rfc/rfc3382.txt @@ -0,0 +1,2131 @@ + + + + + + +Network Working Group R. deBry +Request for Comments: 3382 Utah Valley State College +Updates: 2910, 2911 R. Herriot +Category: Standards Track Consultant + T. Hastings + K. Ocke + P. Zehler + Xerox Corporation + September 2002 + + + Internet Printing Protocol (IPP): + The 'collection' attribute syntax + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document specifies an OPTIONAL attribute syntax called + 'collection' for use with the Internet Printing Protocol (IPP/1.0 and + IPP/1.1). A 'collection' is a container holding one or more named + values, which are called "member" attributes. A collection allows + data to be grouped like a PostScript dictionary or a Java Map. This + document also specifies the conformance requirements for a definition + document that defines a collection attribute. Finally, this document + gives some illustrative example collection attribute definitions that + are not intended as actual attribute specifications. + +Table of Contents + + 1 Introduction.....................................................3 + 1.1 Problem Statement..............................................3 + 1.2 Solution.......................................................3 + 2 Terminology......................................................4 + 2.1 Conformance Terminology........................................4 + 2.2 Other terminology..............................................5 + 3 Definition of a Collection Attribute.............................5 + 3.1 Information to Include.........................................5 + + + +deBry, et. al. Standards Track [Page 1] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + 3.2 Nested Collections.............................................9 + 4 Collection Attributes as Attributes in Operations................9 + 4.1 General Rules..................................................9 + 4.2 Unsupported Values.............................................9 + 5 Example definition of a collection attribute.....................9 + 5.1 media-col (collection)........................................10 + 5.1.1 media-color (type3 keyword | name(MAX)......................10 + 5.1.2 media-size (collection).....................................11 + 5.2 media-col-default (collection)................................11 + 5.3 media-col-ready (1setOf collection)...........................12 + 5.4 media-col-supported (1setOf type2 keyword)....................12 + 6 A Second Example Definition Of A Collection Attribute...........12 + 7 Encoding........................................................13 + 7.1 Additional tags defined for representing a collection + attribute value...............................................13 + 7.2 Example encoding: "media-col" (collection)....................14 + 8 Legacy issues...................................................20 + 9 IANA Considerations.............................................20 + 10 Internationalization Considerations............................20 + 11 Security Considerations........................................21 + 12 References.....................................................21 + Appendix A: Encoding Example of a Simple Collection (Informative).22 + Appendix B: Encoding Example of 1setOf Collection (Informative)...25 + Appendix C: Encoding Example of Collection containing 1setOf XXX + attribute (Informative)...............................31 + Appendix D: Description of the Base IPP Documents (Informative)...35 + Authors' Addresses................................................36 + Full Copyright Statement..........................................38 + +Table of Tables + + Table 1 - "media-col" member attributes...........................10 + Table 2 - "media-size" collection member attributes...............11 + Table 3 - Tags defined for encoding the 'collection' attribute + syntax .................................................13 + Table 4 - Overview Encoding of "media-col" collection.............15 + Table 5 - Example Encoding of "media-col" collection..............16 + Table 6 - Overview Encoding of simple collection..................22 + Table 7 - Example Encoding of simple collection...................22 + Table 8 - Overview Encoding of 1setOf collection..................25 + Table 9 - Example Encoding of 1setOf collection...................26 + Table 10 - Overview Encoding of collection with 1setOf value......31 + Table 11 - Example Encoding of collection with 1setOf value.......32 + + + + + + + + +deBry, et. al. Standards Track [Page 2] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + +1 Introduction + + This document is an OPTIONAL extension to IPP/1.0 [RFC2565, RFC2566] + and IPP/1.1 [RFC2911, RFC2910]. For a description of the base IPP + documents see Appendix D. + +1.1 Problem Statement + + The IPP Model and Semantics [RFC2911] supports most of the common + data structures that are available in programming languages. It + lacks a mechanism for grouping several attributes of different types. + The Java language uses the Map to solve this problem and PostScript + has a dictionary. The new mechanism for grouping attributes together + (called 'collection' mechanism) must allow for optional members and + the subsequent addition of new members. + + The 'collection' mechanism must be encoded in a manner consistent + with existing 1.0 and 1.1 parsing rules (see [RFC2910]). Current 1.0 + and 1.1 parsers that don't support the 'collection' mechanism must + not confuse collections or parts of a collection they receive with + other attributes. + +1.2 Solution + + The new mechanism is a new IPP attribute syntax called a + 'collection'. As such, each collection value is a value of an + attribute whose attribute syntax type is defined to be a + 'collection'. Such an attribute is called a collection attribute. + The name of the collection attribute serves to identify the + collection value in an operation request or response, as with any + attribute value. + + The 'collection' attribute syntax is a container holding one or more + named values (i.e., attributes), which are called member attributes. + Each collection attribute definition document lists the mandatory and + optional member attributes of each collection value. A collection + value is similar to an IPP attribute group in a request or a + response, such as the operation attributes group. They both consist + of a set of attributes. + + As with any attribute syntax, the document that defines a collection + attribute specifies whether the attribute is single-valued + (collection) or multi-valued (1setOf collection). If the attribute + is multi-valued (1setOf collection), each collection value MUST be a + separate instance of a single definition of a collection, i.e., it + MUST have the same member attributes except for OPTIONAL member + attributes. If we view each collection definition as a separate + syntax type, this rule continues the IPP/1.1 notion that each + + + +deBry, et. al. Standards Track [Page 3] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + attribute has a single type or pattern (e.g., "keyword | name" is a + pattern). Without this rule, the supported values would be more + difficult to describe and the mechanism defined in item 4 of section + 3.1 would not be sufficient. + + The name of each member attribute MUST be unique for a collection + attribute, but MAY be the same as the name of a member attribute in + another collection attribute and/or MAY be the same as the name of an + attribute that is not a member of a collection. The rules for naming + member attributes are given in section 3.1. + + Each member attribute can have any attribute syntax type, including + 'collection', and can be either single-valued or multi-valued. The + length of a collection value is not limited. However, the length of + each member attribute MUST NOT exceed the limit of its attribute + syntax. + + The member attributes in a collection MAY be in any order in a + request or response. When a client sends a collection attribute to + the Printer, the order that the Printer stores the member attributes + of the collection value and the order returned in a response MAY be + different from the order sent by the client. + + A collection value MUST NOT contain two or more member attributes + with the same attribute name. Such a collection is mal-formed. + Clients MUST NOT submit such malformed requests and Printers MUST NOT + return such malformed responses. If such a malformed request is + submitted to a Printer, the Printer MUST (depending on + implementation) either (1) reject the request with the 'client- + error-bad-request' status code (see [RFC2911] section 13.1.4.1), or + (2) accept the request and use only one of each duplicate member + attributes. + +2 Terminology + + This section defines terminology used throughout this document. + +2.1 Conformance Terminology + + Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD + NOT, MAY, NEED NOT, and OPTIONAL, have special meaning relating to + conformance as defined in BCP 14, RFC 2119 [RFC2119] and [RFC2911], + section 12.1. If an implementation supports the extension defined in + this document, then these terms apply; otherwise, they do not. These + terms define conformance to this document only; they do not affect + conformance to other documents, unless explicitly stated otherwise. + + + + + +deBry, et. al. Standards Track [Page 4] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + +2.2 Other terminology + + This document uses terms such as Job object (or Job), IPP Printer + object (or Printer), "operation", "request", response", "attributes", + "keywords", and "support". These terms have special meaning and are + defined in the model terminology [RFC2911] section 12.2. The + following additional terms are introduced in this document: + + collection: an attribute syntax in which each attribute value is a + set of attributes, called member attributes. + + member attribute: an attribute that is defined to be used as one + of the attributes in a collection. + + collection attribute: an attribute whose definition specifies the + 'collection' attribute syntax and each of the member attributes + that MAY occur in a collection attribute value. + +3 Definition of a Collection Attribute + + This section describes the requirements for any collection attribute + definition. + +3.1 Information to Include + + When a specification document defines an "xxx" collection attribute, + i.e., an attribute whose attribute syntax type is 'collection' or + '1setOf collection'; the definition document MUST include the + following aspects of the attribute semantics. Suppose the "xxx" + collection attribute contains N member attributes named "aaa1", + "aaa2", ..., "aaaN" ("aaaI" represents any one of these N member + attributes). + + 1. The name of the collection attribute MUST be specified (e.g., + "xxx"). The selection of the name "xxx" MUST follow the same + rules for uniqueness as for attributes of any other syntax type, + (as defined by IPP/1.1) unless "xxx" is a member attribute of + another collection. Then the selection of the name "xxx" MUST + follow the rules for uniqueness defined in item 5a) of this list. + + 2. The collection attribute syntax MUST be of type 'collection' or + '1setOf collection'. + + 3. The context of the collection attribute MUST be specified, i.e., + whether the attribute is an operation attribute, a Job Template + attribute, a Job Description attribute, a Printer Description + attribute, a member attribute of a particular collection + attribute, etc. + + + +deBry, et. al. Standards Track [Page 5] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + 4. An "xxx-supported" attribute MUST be specified and it has one of + the following two forms: + + a) "xxx-supported" is a "1setOf collection", which enumerates all + of the supported collection values of "xxx". If a collection + of this form contains a nested collection, it MUST be of the + same form. + + For example, "media-size-supported" might have the values {{x- + dimension:210, y-dimension:297},{x-dimension:297, y- + dimension:420}} to show that it supports two values of "media + size": A4 (210x297) and A3 (297x420). It does not support + other combinations of "x-dimension" and "y-dimension" member + attributes, such as 210x420 or 297x297, and it does not support + non-enumerated values, such as 420x595. + + b) "xxx-supported" is a "1setOf type2 keyword", which enumerates + the names of all of the member attributes of "xxx": "aaa1", + "aaa2", ..., "aaaN". If a collection of this form contains a + nested collection, it MAY be of either form. See item 5f) + below for details on supported values of member attributes. + + For example, "media-col-supported" might have the keyword + values: "media-size" and "media-color". + + 5. The member attributes MUST be defined. For each member attribute, + the definition document MUST provide the following information: + + a) The member attribute's name (e.g., "aaa") MUST be unique within + the collection being defined and MUST either: + + i) reuse the attribute name of another attribute (that is + unique across the entire IPP attribute name space) and + have the same syntax and semantics as the reused attribute + (if the condition of item 4b) above is met). For example, + a member attribute definition could reuse the IPP/1.1 + "media" attribute. + + ii) potentially occur elsewhere in the entire IPP attribute + name space. (if the condition of item 4a) above is met). + For example, a member attribute could be "x-dimension", + which could potentially occur in another collection or as + an attribute outside of a collection. + + iii) be unique across the entire IPP attribute name space (if + the condition of item 4b) above is met). For example, a + member attribute could be "media-color" which must be + unique across the entire IPP attribute name space. + + + +deBry, et. al. Standards Track [Page 6] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + b) Whether the member attribute is REQUIRED or OPTIONAL for the + Printer to support. + + c) Whether the member attribute is REQUIRED or OPTIONAL for the + client to supply in a request. + + d) The member attribute's syntax type, which can be any attribute + syntax, including '1setOf X', 'collection', and '1setOf + collection'. If this attribute name reuses the name of another + attribute (case of item a1 above), it MUST have the same + attribute syntax, including cardinality (whether or not + 1setOf). + + e) The semantics of the "aaa" member attribute. The semantic + definition MUST include a description of any constraint or + boundary conditions the member attribute places on the + associated attribute, especially if the attribute reuses the + name of another attribute (case of item a1 above). + + f) The supported values for each "aaaI" member attribute (of the + member attributes "aaa1", "aaa2", ..., "aaaN") is specified by + one of two mechanisms. + + i) If "xxx-supported" is a "1setOf collection" (see item 4a) + above), the value for each "aaaI" is specified in each + collection value of "xxx-supported", in the context of + other member attributes. That is, "xxx-supported" + enumerates all supported values of "xxx". + + ii) If the value of "xxx-supported" is a "1setOf type2 + keyword" (see item 4b) above), the supported values of + "aaaI" are the values specified by either i) the "aaaI- + supported" attribute or ii) the definition of the member + attribute "aaaI" within the document defining the "xxx" + attribute. The values of each member attribute "aaaI" are + specified independently of other member attributes, though + a Printer is not required to support all combinations of + supported values. + + For example, "media-col-supported" might have the keyword + values: "media-size" and "media-color". Using the first + method for defining supported values (an "aaaI-supported" + attribute), the collection values of "media-col" are + combinations of values of "media-size-supported" and + "media-color-supported". If "media-size-supported" has + the values of '210x297' and '297x420' and "media-color- + supported" has the values of 'white' and 'pink', the + + + + +deBry, et. al. Standards Track [Page 7] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Printer might support only the combinations 'white- + 210x297', 'pink-210x297' and 'white-297x420', and not + 'pink-297x420'. + + If a collection contains a member "aaaI", whose syntax + type is "text", the supported values would probably be + defined by the definition of "xxx" rather than by the + attribute "aaaI-supported". + + g) the default value of each "aaaI" member attribute if it is + OPTIONAL for a client to supply the "aaa" member attribute in a + request. The default value is specified by the attribute's + definition within a document and MUST be one of the following: + + i) a fixed default + + ii) a mechanism by which the Printer determines default + + iii) an indefinite default that is left to the implementation. + + iv) an attribute that the Printer uses to determine the + default + + 6. The default value of "xxx", if a client does not supply it. The + default value is specified by the attribute's definition within a + document and MUST be one of the following: + + a) a fixed default + + b) a mechanism by which the Printer determines default + + c) an indefinite default that is left to the implementation + + d) a Printer attribute "xxx-default" which is a collection with + the same member attributes as "xxx". If optional member + attributes are absent, the Printer uses the defaulting rules of + item 5g) above. + + 7. The "xxx-ready (1setOf collection)" attribute, if human + intervention is required to make many of the supported values + available. For example, "media-col" is an attribute which has a + "ready" attribute. Most attributes do not have a "ready" + attribute. + + + + + + + + +deBry, et. al. Standards Track [Page 8] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + +3.2 Nested Collections + + A member attribute may have a syntax type of 'collection' or '1setOf + collection', in which case it is called a nested collection + attribute. The rules for a nested collection attribute are the same + as for a collection attribute as specified in section 3.1. + +4 Collection Attributes as Attributes in Operations + +4.1 General Rules + + A collection value is like any other IPP/1.1 value, except that it is + structured. The rules for attributes with collection values are the + same as for attributes of any other syntax type (see IPP/1.1), be + they in any group of a request of a response. + +4.2 Unsupported Values + + The rules for returning an unsupported collection attribute are an + extension to the current rules: + + 1. If the entire collection attribute is unsupported, then the + Printer returns just the collection attribute name with the + 'unsupported' out-of-band value (see the beginning of [RFC2911] + section 4.1) in the Unsupported Attributes Group. + + 2. If a collection contains unrecognized, unsupported member + attributes and/or conflicting values, the attribute returned in + the Unsupported Group is a collection containing the unrecognized, + unsupported member attributes, and/or conflicting values. The + unrecognized member attributes have an out-of-band value of + 'unsupported' (see the beginning of [RFC2911] section 4.1). The + unsupported member attributes and conflicting values have their + unsupported or conflicting values. + +5 Example definition of a collection attribute + + In some printing environments, it is desirable to allow the client to + select the media by its properties, e.g., weight, color, size, etc., + instead of by name. In IPP/1.1 (see [RFC2911]), the "media (type3 + keyword | name) Job Template attribute allows selection by name. It + is tempting to extend the "media" attribute syntax to include + "collection", but then existing clients could not understand default + or supported media values that use the collection value. To preserve + interoperability, a new attribute MUST BE added, e.g., "media-col + (collection)". The following subsections contain a sample definition + of a simplified "media-col" attribute. The definition follows the + rules in section 3. + + + +deBry, et. al. Standards Track [Page 9] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + All of the example attribute definitions in this document are + illustrative examples, rather than actual definitions. These + examples are intended to illustrate how to define collection + attributes. Other documents MUST define collection attributes for + use in actual interchange. Such definitions may be very similar to + the examples in this document, since we attempted to pick useful + examples. + + Note: we picked the name "media-col" because the name "media" is + already in use. Ordinarily the collection attribute would have a + name like any other attribute and would not end in "col". + + The member attributes of "media-col" attribute ("media-color (type 3 + keyword)" and "media-size (collection)") both follow the naming rules + of item 4a3 of section 3, i.e., the names are unique across the + entire IPP attribute name space. The member attributes of the + "media-size (collection)" member attribute ("x-dimension + (integer(0:MAX))" and "y-dimension (integer(0:MAX))") both follow the + naming rules of item 4a2 of section 3, i.e., they potentially occur + elsewhere in the IPP attribute name space. + +5.1 media-col (collection) + + The "media-col" (collection) attribute augments the IPP/1.1 [RFC2911] + "media" attribute. This collection attribute enables a client end + user to submit a list of media characteristics to the Printer. When + the client specifies media using the "media-col" collection + attribute, the Printer object MUST match the requested media exactly. + The 'collection' consists of the following member attributes: + + Table 1 - "media-col" member attributes + + Attribute name attribute syntax request Printer + Support + + media-color type3 keyword | name (MAX) MAY MUST + + media-size collection MUST MUST + + The definitions for the member attributes is given in the following + sub-sections: + +5.1.1 media-color (type3 keyword | name(MAX) + + This member attribute identifies the color of the media. Valid + values are 'red', 'white' and 'blue'. + + + + + +deBry, et. al. Standards Track [Page 10] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + The "media-color-supported" (1setOf (type3 keyword | name(MAX))) + Printer attribute identifies the values of this "media-color" member + attribute that the Printer supports, i.e., the colors supported. + + If the client omits this member attribute, the Printer determines the + value in an implementation dependent manner. + +5.1.2 media-size (collection) + + This member attribute identifies the size of the media. The + 'collection' consists of the member attributes shown in Table 2: + + Table 2 - "media-size" collection member attributes + + Attribute name attribute syntax request Printer + Support + + x-dimension integer (0:MAX) MUST MUST + + y-dimension integer (0:MAX) MUST MUST + + The definitions for the member attributes are given in the following + sub-sections: + +5.1.2.1 x-dimension (integer(0:MAX)) + + This attribute identifies the width of the media in inch units along + the X axis. + +5.1.2.2 y-dimension (integer(0:MAX)) + + This attribute identifies the height of the media in inch units along + the Y axis. + + The "media-size-supported" (1setOf collection) Printer attribute + identifies the values of this "media-size" member attribute that the + Printer supports, i.e., the size combinations supported. The names + of the member attributes are the same as the member attributes of the + "media-size" collection attribute, namely "x-dimension", and "y- + dimension", since they have the same attribute syntax and the same + semantics. + +5.2 media-col-default (collection) + + The "media-col-default" Printer attribute specifies the media that + the Printer uses, if any, if the client omits the "media-col" and + "media". Job Template attributes in the Job Creation operation and + the PDL do not include a media specification. The member attributes + + + +deBry, et. al. Standards Track [Page 11] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + are defined in Table 1. A Printer MUST support the same member + attributes for this default collection attribute as it supports for + the corresponding "media-col" Job Template attribute. + +5.3 media-col-ready (1setOf collection) + + The "media-col-ready" Printer attribute identifies the media that are + available for use without human intervention, i.e., the media that + are ready to be used without human intervention. The collection + value MUST have all of the member attributes that are supported in + Table 1. + +5.4 media-col-supported (1setOf type2 keyword) + + The "media-col-supported" Printer attribute identifies the keyword + names of the member attributes supported in the "media-col" + collection Job Template attribute, i.e., the keyword names of the + member attributes in Table 1 that the Printer supports. + +6 A Second Example Definition Of A Collection Attribute + + All of the example attribute definitions in this document are + illustrative examples, rather than actual definitions. These + examples are intended to illustrate how to define collection + attributes. Other documents MUST define collection attributes for + use in actual interchange. Such definitions may be very similar to + the examples in this document, since we attempted to pick useful + examples. + + In some printing environments, it is desirable to allow the client to + select the media for the job start sheet. The reason for not adding + the 'collection' attribute syntax to the existing "job-sheets" Job + Template attribute is the same as for "media". Instead, a new Job + Template attribute is introduced, e.g., "job-sheet-col (collection)". + + The member attributes of "job-sheet-col" attribute ("job-sheets (type + 3 keyword)" and "media (type3 keyword | name)") both follow the + naming rules of item 4a1 of section 3, i.e., they reuse existing IPP + attributes. According to the rules, their supported values come from + the existing IPP attributes: "job-sheets-supported" and "media- + supported". However, their default values do not come from "job- + sheets-default" and "media-default", respectively. Rather, the + definition of "job-sheet-col" says that "job-sheets (type 3 keyword)" + is required and if "media (type3 keyword | name)" is absent, the + Printer uses the same media as the rest of the job uses. + + + + + + +deBry, et. al. Standards Track [Page 12] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + If "job-sheet-col" attribute was defined to contain the member + attribute "job-sheet-media (type3 keyword | name)" instead of "media + (type3 keyword | name)", then the definition would also have to + specify a "job-sheet-media-supported (1setOf (type3 keyword | name))" + whose values would be independent of "media-supported (1setOf (type3 + keyword | name))" and would be set separately by a System + Administrator. + + The actual text for the definition of the attribute is left as an + exercise for the reader. + +7 Encoding + + This section defines the additional encoding tags used according to + [RFC2910] and gives an example of their use. The encoding tags + defined in this document MUST be used by all collection attributes + defined in other documents. However, the example of their use is + illustrative only. + +7.1 Additional tags defined for representing a collection attribute + value + + The 'collection' attribute syntax uses the tags defined in Table 3. + + Table 3 - Tags defined for encoding the 'collection' attribute syntax + + Tag name Tag + value Meaning + + begCollection 0x34 Begin the collection attribute value. + + endCollection 0x37 End the collection attribute value. + + memberAttrName 0x4A The value is the name of the + collection member attribute + + When encoding a collection attribute "xxx" that contains an attribute + "aaa" and is not inside another collection, the encoding follows + these rules: + + 1. The beginning of the collection is indicated with a value tag that + MUST be syntax type 'begCollection' (0x34) with a name length and + Name field that represent the name of the collection attribute + ("xxx") as with any attribute, followed by a value. The Printer + MAY ignore the value and its length MAY be 0. In the future, + however, this field MAY contain useful information, such as the + collection name (cf. the name of a C struct). + + + + +deBry, et. al. Standards Track [Page 13] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + 2. Each member attribute is encoded as a sequence of two or more + values that appear to be part of a single multi-valued attribute, + i.e., 1setOf. The first value after the 'begCollection' value has + the attribute syntax, 'memberAttrName' (0x4A), and its value holds + the name of the first member attribute (e.g., "aaa"). The second + value holds the first member's attribute value, which can be of + any attribute syntax, except 'memberAttrName' or 'endCollection'. + If the first member's attribute value is multi-valued, the third + value holds the second value of the first member's value. + Otherwise, the third value holds the name of second member + attribute (e.g., "bbb"), and its attribute syntax is + 'memberAttrName'. In this case, the fourth member's value is the + value of "bbb". + + Note that the technique of encoding a 'collection' as a '1setOf' + makes it easy for a Printer that doesn't support a particular + collection attribute (or the collection attribute syntax at all) + to simply skip over the entire collection value. + + 3. The end of the collection is indicated with a value tag that MUST + be syntax type 'endCollection' (e.g., 0x37) and MAY have a zero + name length and a zero value length. In the future, this field + MAY contain useful information, such as the collection name that + matches the one in the 'begCollection' . + + 4. It is valid to have a member attribute that is itself, a + collection attribute, i.e., collections can be nested within + collections. This is represented by the occurrence of a member + attribute that is of attribute syntax type 'begCollection'. Such + a collection is terminated by a matching 'endCollection'. The + name of such a member attribute is in the immediately preceding + value, whose syntax type is 'memberAttrName'. + + 5. It is valid for a collection attribute to be multi-valued, i.e., + have more than one collection value. If the next attribute + immediately following the 'endCollection' has a zero name length + and a tag of 'begCollection', then the collection attribute is a + multi-valued collection, as with any attribute. This statement + applies to collections within collections and collections that are + not in collections. + +7.2 Example encoding: "media-col" (collection) + + The collection specified in section 5 is used for the encoding + example shown in Table 5. The example also shows nested collections, + since the "media-size" member attribute is a 'collection. The + encoding example represents a blue 4x6-index card and takes 216 + octets. The Appendices contain more complex examples. + + + +deBry, et. al. Standards Track [Page 14] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Additional examples have been included in the appendices. + + The overall structure of the two collection values can be pictorially + represented as: + + "media-col" = + { "media-color" = 'blue'; + "media-size" = + { "x-dimension" = 6; + "y-dimension" = 4 + } + }, + + The full encoding is in table 5. A simplified view of the encoding + looks like this: + + Table 4 - Overview Encoding of "media-col" collection + + Tag Value Name Value + + begCollection media-col "" + + memberAttrName "" media-color + + keyword "" blue + + memberAttrName "" media-size + + begCollection "" "" + + memberAttrName "" x-dimension + + integer "" 6 + + memberAttrName "" y-dimension + + integer "" 4 + + endCollection "" "" + + endCollection "" "" + + + + + + + + + + +deBry, et. al. Standards Track [Page 15] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Table 5 - Example Encoding of "media-col" collection + + Octets Symbolic Value Protocol comments + field + + 0x34 begCollection value-tag beginning of the "media- + col" collection attribute + + 0x0009 name- length of (collection) + length attribute name + + media-col media-col name name of (collection) + attribute + + 0x0000 value- defined to be 0 for this + length type + + no value (since value- + length was 0) + + 0x4A memberAttrName value-tag starts a new member + attribute: "media-color" + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x000B value- length of "media-color" + length keyword + + media-color media-color value value is name of 1st + member attribute + + + 0x44 keyword type value-tag keyword type + + 0x0000 name- 0 indicates 1setOf + length + + no name (since name-length + was 0) + + + + + + + + +deBry, et. al. Standards Track [Page 16] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + 0x0004 value- + length + + blue blue value value of 1st member + attribute + + + 0x4A memberAttrName value-tag starts a new member + attribute: "media-size" + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x000A value- length of "media-size" + length keyword + + media-size media-size value Name of 2nd member + attribute + + 0x34 begCollection value-tag Beginning of the "media- + size" collection attribute + which is a sub-collection + + 0x0000 name- 0 indicates 1setOf + length + + no name (since name-length + was 0) + + 0x0000 value- collection attribute names + length have no value + + no value (since value- + length was 0) + + 0x4A memberAttrName value-tag starts a new member + attribute: "x-dimension" + + + + + + + + +deBry, et. al. Standards Track [Page 17] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x000B value- length of "x-dimension" + length keyword + + x-dimension x-dimension value name of 1st sub- + collection member + attribute + + + 0x21 integer type value-tag attribute type + + 0x0000 name- 0 indicates 1setOf + length + + no name (since name-length + was 0) + + 0x0004 value- length of an integer = 4 + length + + 0x0006 value value of 1st sub- + collection member + attribute + + 0x4A memberAttrName value-tag starts a new member + attribute: "y-dimension" + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x000B value- length of the "y- + length dimension" keyword + + + + + + + + +deBry, et. al. Standards Track [Page 18] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + y-dimension y-dimension value name of 2nd sub- + collection member + attribute + + 0x21 integer type value-tag attribute type + + 0x0000 name- 0 indicates 1setOf + length + + no name (since name-length + was 0) + + 0x0004 value- length of an integer = 4 + length + + 0x0004 value value of 2nd sub- + collection member + attribute + + 0x37 endCollection value-tag end of the sub-collection + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x0000 value- defined to be 0 for this + length type + + no value (since value- + length was 0) + + 0x37 endCollection value-tag end of the 1st collection + value in 1setOf + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + + + + + + + + + +deBry, et. al. Standards Track [Page 19] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + no name (since name-length + was 0) + + 0x0000 value- defined to be 0 for this + length type + + no value (since value- + length was 0) + +8 Legacy issues + + IPP 1.x Printers and Clients will gracefully ignore collections and + its member attributes if it does not understand the collection. The + begCollection and endCollection elements each look like an attribute + with an attribute syntax that the recipient doesn't support and so + should ignore the entire attribute. The individual member attributes + and their values will look like a 1setOf values of the collection + attribute, so that the Printer simply ignores the entire attribute + and all of its values. Returning unsupported attributes is also + simple, since only the name of the collection attribute is returned + with the 'unsupported' out-of-band value (see section 4.2). + +9 IANA Considerations + + The following table provides registration for the 'collection' + attribute syntax defined in this document. This is to be registered + according to the procedures in RFC 2911 [RFC2911] section 6.3. + + Tag value: Attribute Syntaxes: Ref. Section: + collection RFC 3382 3 + 0x34 begCollection RFC 3382 7.1 + 0x37 endCollection RFC 3382 7.1 + 0x4A memberAttrName RFC 3382 7.1 + + The resulting attribute syntax registration will be published in the + http://www.iana.org/assignments/ipp-registrations registry. + +10 Internationalization Considerations + + This attribute syntax by itself has no impact on + internationalization. However, the member attributes that are + subsequently defined for use in a collection may have + internationalization considerations, as may any attribute, according + to [RFC2911]. + + + + +deBry, et. al. Standards Track [Page 20] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + +11 Security Considerations + + This attribute syntax causes no more security concerns than any other + attribute syntax. It is only the attributes that are subsequently + defined, to use this or any other attribute syntax, that may have + security concerns, depending on the semantics of the attribute, + according to [RFC2911]. + +12 References + +12.1 Normative References + + [RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet + Printing Protocol/1.1: Encoding and Transport", RFC 2910, + September 2000. + + [RFC2911] Isaacson, S., deBry, R., Hastings, T., Herriot, R. and P. + Powell, "Internet Printing Protocol/1.1: Model and + Semantics", RFC 2911, September 2000. + +12.2 Informative References + + [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet + Printing Protocol/1.0: Encoding and Transport", RFC 2565, + April 1999. + + [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. + Powell, "Internet Printing Protocol/1.0: Model and + Semantics", RFC 2566, April 1999. + + [RFC2567] Wright, D., "Design Goals for an Internet Printing + Protocol", RFC 2567, April 1999. + + [RFC2568] Zilles, S., "Rationale for the Structure and Model and + Protocol for the Internet Printing Protocol", RFC 2568, + April 1999. + + [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, + "Mapping between LPD and IPP Protocols", RFC 2569, April + 1999. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, + L., Leach, P. and T. Berners-Lee, "Hypertext Transfer + Protocol - HTTP/1.1", RFC 2616, June 1999. + + [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C. and H. + Holst, "Internet Printing Protocol/1.1: Implementor's + Guide", RFC 3196, November 2001. + + + +deBry, et. al. Standards Track [Page 21] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + +Appendix A: Encoding Example of a Simple Collection (Informative) + + The overall structure of the collection value can be pictorially + represented as: + + "media-size" = + { "x-dimension" = 6; + "y-dimension" = 4 + } + + A simplified view of the encoding would look like this: + + Table 6 - Overview Encoding of simple collection + + Tag Value Name Value + + begCollection media-size "" + + memberAttrName "" x-dimension + + integer "" 6 + + memberAttrName "" y-dimension + + integer "" 4 + + endCollection "" "" + + Note: "" represents a name or value whose length is 0. + + Table 7 - Example Encoding of simple collection + + Octets Symbolic Value Protocol comments + field + + 0x34 begCollection value-tag beginning of the "media- + size" collection attribute + + 0x000A name- length of (collection) + length attribute name + + media-size media-size name name of (collection) + attribute + + + + + + + + +deBry, et. al. Standards Track [Page 22] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + 0x0000 value- defined to be 0 for this + length type + + no value (since value- + length was 0) + + 0x4A memberAttrName value-tag starts member attribute: + "x-dimension" + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x000B value- length of "x-dimension" + length keyword + + x-dimension x-dimension value name of 1st collection + member attribute + + + 0x21 integer type value-tag attribute type + + 0x0000 name- 0 indicates 1setOf + length + + no name (since name-length + was 0) + + 0x0004 value- length of an integer = 4 + length + + 0x0006 value value of 1st collection + member attribute + + 0x4A memberAttrName value-tag starts a new member + attribute: "y-dimension" + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + + + +deBry, et. al. Standards Track [Page 23] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + 0x000B value- length of the "y- + length dimension" keyword + + y-dimension y-dimension value name of 2nd collection + member attribute + + 0x21 integer type value-tag attribute type + + 0x0000 name- 0 indicates 1setOf for + length media-size + + no name (since name-length + was 0) + + 0x0004 value- length of an integer = 4 + length + + 0x0004 value value of 2nd collection + member attribute + + 0x37 endCollection value-tag end of the collection + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x0000 value- defined to be 0 for this + length type + + no value (since value- + length was 0) + + + + + + + + + + + + + + + +deBry, et. al. Standards Track [Page 24] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + +Appendix B: Encoding Example of 1setOf Collection (Informative) + + The overall structure of the collection value can be pictorially + represented as: + + "media-size-supported" = + { "x-dimension" = 6; + "y-dimension" = 4 + }, + { "x-dimension" = 3; + "y-dimension" = 5 + }; + + A simplified view of the encoding would look like this: + + Table 8 - Overview Encoding of 1setOf collection + + Tag Value Name Value + + begCollection media-size- "" + supported + + memberAttrName "" x-dimension + + integer "" 6 + + memberAttrName "" y-dimension + + integer "" 4 + + endCollection "" "" + + begCollection "" "" + + memberAttrName "" x-dimension + + integer "" 3 + + memberAttrName "" y-dimension + + integer "" 5 + + endCollection "" "" + + + + + + + + +deBry, et. al. Standards Track [Page 25] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Table 9 - Example Encoding of 1setOf collection + + Octets Symbolic Value Protocol comments + field + + 0x34 begCollection value-tag beginning of the "media- + size-supported (1setOf + collection" attribute + + 0x00014 name- length of (collection) + length attribute name + + media-size- media-size- name name of (collection) + supported supported attribute + + 0x0000 value- defined to be 0 for this + length type + + no value (since value- + length was 0) + + 0x4A memberAttrName value-tag starts member attribute: + "x-dimension" + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x000B value- length of "x-dimension" + length keyword + + x-dimension x-dimension value name of 1st collection + member attribute + + 0x21 integer type value-tag attribute type + + 0x0000 name- 0 indicates 1setOf + length + + no name (since name-length + was 0) + + + + + + + + +deBry, et. al. Standards Track [Page 26] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + 0x0004 value- length of an integer = 4 + length + + 0x0006 value value of 1st collection + member attribute + + 0x4A memberAttrName value-tag starts member attribute: + "y-dimension" + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x000B value- length of the "y- + length dimension" keyword + + y-dimension y-dimension value name of 2nd collection + member attribute + + 0x21 integer type value-tag attribute type + + 0x0000 name- 0 indicates 1setOf + length + + no name (since name-length + was 0) + + 0x0004 value- length of an integer = 4 + length + + 0x0004 value value of 2nd collection + member attribute + + 0x37 endCollection value-tag end of the collection + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + + + + + +deBry, et. al. Standards Track [Page 27] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + 0x0000 value- defined to be 0 for this + length type + + no value (since value- + length was 0) + + 0x34 begCollection value-tag beginning of the 2nd + member of the 1setOf + "sizes-avail " collection + attribute + + 0x0000 name- Zero length name indicates + length this is member of previous + attribute + + name no name (since name-length + was 0) + + 0x0000 value- defined to be 0 for this + length type + + no value (since value- + length was 0) + + 0x4A memberAttrName value-tag starts member attribute: + "x-dimension" + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x000B value- length of "x-dimension" + length keyword + + x-dimension x-dimension value name of 1st collection + member attribute + + 0x21 integer type value-tag attribute type + + + + + + + + +deBry, et. al. Standards Track [Page 28] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + 0x0000 name- 0 indicates 1setOf + length + + no name (since name-length + was 0) + + 0x0004 value- length of an integer = 4 + length + + 0x0003 value value of 1st collection + member attribute + + 0x4A memberAttrName value-tag starts member attribute: + "y-dimension" + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x000B value- length of the "y- + length dimension" keyword + + y-dimension y-dimension value name of 2nd collection + member attribute + + 0x21 integer type value-tag attribute type + + 0x0000 name- 0 indicates 1setOf + length + + no name (since name-length + was 0) + + 0x0004 value- length of an integer = 4 + length + + 0x0005 value value of 2nd collection + member attribute + + + + + + + + +deBry, et. al. Standards Track [Page 29] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + 0x37 endCollection value-tag end of the 1setOf + collection value + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x0000 value- defined to be 0 for this + length type + + no value (since value- + length was 0) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +deBry, et. al. Standards Track [Page 30] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + +Appendix C: Encoding Example of Collection containing 1setOf XXX + attribute (Informative) + + The overall structure of the collection value can be pictorially + represented as: + + "wagons" = + { "colors" = red, blue; + "sizes" = 4, 6, 8 + } + + A simplified view of the encoding would look like this: + + Table 10 - Overview Encoding of collection with 1setOf value + + Tag Value Name Value + + begCollection wagons "" + + memberAttrName "" colors + + keyword "" red + + keyword "" blue + + memberAttrName "" sizes + + integer "" 4 + + integer "" 6 + + integer "" 8 + + endCollection "" "" + + + + + + + + + + + + + + + + + +deBry, et. al. Standards Track [Page 31] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Table 11 - Example Encoding of collection with 1setOf value + + Octets Symbolic Value Protocol comments + field + + 0x34 begCollection value-tag beginning of the "wagons" + collection attribute + + 0x0005 name- length of (collection) + length attribute name + + wagons wagons name name of (collection) + attribute + + 0x0000 value- defined to be 0 for this + length type + + no value (since value- + length was 0) + + 0x4A memberAttrName value-tag starts a new member + attribute: "colors" + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x0006 value- length of "colors" keyword + length + + colors colors value value is name of 1st + member attribute + + 0x44 keyword type value-tag keyword type + + 0x0000 name- 0 indicates 1setOf wagons + length + + no name (since name-length + was 0) + + 0x0004 value- + length + + + + + + +deBry, et. al. Standards Track [Page 32] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + blue blue value value of 1st member + attribute + + 0x44 keyword type value-tag keyword type + + 0x0000 name- 0 indicates 1setOf wagons + length + + no name (since name-length + was 0) + + 0x0003 value- + length + + red red value value of 1st member + attribute + + 0x4A memberAttrName value-tag starts a new member + attribute: "sizes" + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x0005 value- length of "length-avail" + length keyword + + sizes sizes value Name of 2nd member + attribute + + 0x21 integer type value-tag attribute type + + 0x0000 name- 0 indicates 1setOf wagons + length + + no name (since name-length + was 0) + + 0x0004 value- length of an integer = 4 + length + + + + + + +deBry, et. al. Standards Track [Page 33] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + 0x0004 value 1st value for 1setOf + integer attribute + + 0x21 integer type value-tag attribute type + + 0x0000 name- 0 indicates 1setOf + length + + no name (since name-length + was 0) + + 0x0004 value- + length length of an integer = 4 + + 0x0006 value 2nd value for 1setOf + integer attribute + + 0x21 integer type value-tag attribute type + + 0x0000 name- 0 indicates 1setOf + length + + no name (since name-length + was 0) + + 0x0004 value- length of an integer = 4 + length + + 0x0008 value 3rd value for 1setOf + integer attribute + + 0x37 endCollection value-tag end of the collection + + 0x0000 name- defined to be 0 for this + length type, so part of 1setOf + + no name (since name-length + was 0) + + 0x0000 value- defined to be 0 for this + length type + + + + + + + +deBry, et. al. Standards Track [Page 34] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Octets Symbolic Value Protocol comments + field + + no value (since value- + length was 0) + +Appendix D: Description of the Base IPP Documents (Informative) + + The base set of IPP documents includes: + + Design Goals for an Internet Printing Protocol [RFC2567] + Rationale for the Structure and Model and Protocol for the + Internet Printing Protocol [RFC2568] + Internet Printing Protocol/1.1: Model and Semantics [RFC2911] + Internet Printing Protocol/1.1: Encoding and Transport [RFC2910] + Internet Printing Protocol/1.1: Implementer's Guide [RFC3196] + Mapping between LPD and IPP Protocols [RFC2569] + + The "Design Goals for an Internet Printing Protocol" document takes a + broad look at distributed printing functionality, and it enumerates + real-life scenarios that help to clarify the features that need to be + included in a printing protocol for the Internet. It identifies + requirements for three types of users: end users, operators, and + administrators. It calls out a subset of end user requirements that + are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator + operations have been added to IPP/1.1 [RFC2911, RFC2910]. + + The "Rationale for the Structure and Model and Protocol for the + Internet Printing Protocol" document describes IPP from a high level + view, defines a roadmap for the various documents that form the suite + of IPP specification documents, and gives background and rationale + for the IETF IPP working group's major decisions. + + The "Internet Printing Protocol/1.1: Model and Semantics" document + describes a simplified model with abstract objects, their attributes, + and their operations. The model introduces a Printer and a Job. The + Job supports multiple documents per Job. The model document also + addresses how security, internationalization, and directory issues + are addressed. + + The "Internet Printing Protocol/1.1: Encoding and Transport" document + is a formal mapping of the abstract operations and attributes defined + in the model document onto HTTP/1.1 [RFC2616]. It also defines the + encoding rules for a new Internet MIME media type called + "application/ipp". This document also defines the rules for + transporting over HTTP a message body whose Content-Type is + "application/ipp". This document defines the 'ipp' scheme for + identifying IPP printers and jobs. + + + +deBry, et. al. Standards Track [Page 35] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + The "Internet Printing Protocol/1.1: Implementer's Guide" document + gives insight and advice to implementers of IPP clients and IPP + objects. It is intended to help them understand IPP/1.1 and some of + the considerations that may assist them in the design of their client + and/or IPP object implementations. For example, a typical order of + processing requests is given, including error checking. Motivation + for some of the specification decisions is also included. + + The "Mapping between LPD and IPP Protocols" document gives some + advice to implementers of gateways between IPP and LPD (Line Printer + Daemon) implementations. + +Authors' Addresses + + Roger deBry + Utah Valley State College + Orem, UT 84058 + + Phone: (801) 222-8000 + EMail: debryro@uvsc.edu + + + Tom Hastings + Xerox Corporation + 737 Hawaii St. ESAE 231 + El Segundo, CA 90245 + + Phone: 310-333-6413 + Fax: 310-333-5514 + EMail: hastings@cp10.es.xerox.com + + + Robert Herriot + Consultant + 706 Colorado Ave + Palo Alto, CA 94303 + + Phone: 650-327-4466 + Fax: 650-327-4466 + EMail: bob@herriot.com + + + + + + + + + + + +deBry, et. al. Standards Track [Page 36] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + + Kirk Ocke + Xerox Corp. + 800 Phillips Rd + M/S 128-30E + Webster, NY 14580 + + Phone: (585) 442-4832 + EMail: KOcke@crt.xerox.com + + + Peter Zehler + Xerox Corp. + 800 Phillips Rd + M/S 128-30E + Webster, NY 14580 + + Phone: (585) 265-8755 + EMail: PZehler@crt.xerox.com + + IPP Web Page: http://www.pwg.org/ipp/ + IPP Mailing List: ipp@pwg.org + + To subscribe to the ipp mailing list, send the following email: + + 1) send it to majordomo@pwg.org + 2) leave the subject line blank + 3) put the following two lines in the message body: + subscribe ipp + end + + Implementers of this specification document are encouraged to join + the IPP Mailing List in order to participate in any discussions of + clarification issues and review of registration proposals for + additional attributes and values. In order to reduce spam the + mailing list rejects mail from non-subscribers, so you must subscribe + to the mailing list in order to send a question or comment to the + mailing list. + + + + + + + + + + + + + + +deBry, et. al. Standards Track [Page 37] + +RFC 3382 IPP: The 'collection' attribute syntax September 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +deBry, et. al. Standards Track [Page 38] + |