RFC 3382
Internet Printing Protocol (IPP): The 'collection' attribute syntax
RFC 3382 🎀 Internet Printing Protocol (IPP): The 'collection' attribute syntax
Okay bestie, here's the deets on this one 💅
- Number: RFC 3382
- Series: Network Working Group
- Authors: R. deBry (Utah Valley State College), R. Herriot (Consultant), T. Hastings, K. Ocke, and P. Zehler (all Xerox Corporation)
- Category: Standards Track
- Date: September 2002
- Updates: RFC 2910 and RFC 2911
Status of this Memo ✨
Okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking everyone for discussion and suggestions for improvements 💬 For where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📜 Distribution of this memo is unlimited 🌸
Copyright Notice 🔒
Copyright Notice: Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract 🦋
This doc 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. It's basically a way to group data like a PostScript dictionary or a Java Map, and it's giving organization 🗂️ The doc also lays out the conformance requirements for a definition document that defines a collection attribute. Finally, it shows some illustrative example collection attribute definitions. Those examples are not intended as actual attribute specifications, so don't copy-paste them into production 🙈
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
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..........................................38Table 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.......321 Introduction 🌈
This doc 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 you'd find in programming languages. What it's missing is a way to group several attributes of different types together. Java uses the Map to solve this, and PostScript has a dictionary. So the new grouping mechanism (called the 'collection' mechanism) must allow for optional members and for new members to be added later 🧩
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'. So each collection value is a value of an attribute whose attribute syntax type is defined to be a 'collection'. That kind of attribute is called a collection attribute. Just like any other attribute value, the name of the collection attribute is what identifies the collection value in an operation request or response 🎯
The 'collection' attribute syntax is a container holding one or more named values (aka 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 response, like the operation attributes group, since they both consist of a set of attributes 👯
As with any attribute syntax, the document that defines a collection attribute says 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. In other words, it MUST have the same member attributes, except for OPTIONAL member attributes. If you view each collection definition as its own syntax type, this rule keeps the IPP/1.1 idea that each attribute has a single type or pattern (e.g., "keyword | name" is a pattern) 🔁 Without this rule, the supported values would be way harder to describe, and the mechanism defined in item 4 of section 3.1 wouldn't be enough 😩
The name of each member attribute MUST be unique for a collection attribute. It MAY be the same as the name of a member attribute in another collection attribute, and/or it 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 the Printer stores the member attributes in, and the order returned in a response, MAY be different from the order the client sent them in 🔀
🚩 Heads up: a collection value MUST NOT contain two or more member attributes with the same attribute name. A collection like that is mal-formed. Clients MUST NOT submit such malformed requests, and Printers MUST NOT return such malformed responses. If a malformed request does get 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 attribute.
2 Terminology 📖
This section defines the 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. They're 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 don't. These terms only define conformance to this document. They don't affect conformance to other documents, unless explicitly stated otherwise 🎀
2.2 Other terminology 💬
This document uses terms like 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 ✨
okay so, when a spec doc defines an "xxx" collection attribute (aka an attribute whose attribute syntax type is 'collection' or '1setOf collection') 💖, the definition doc MUST include the following aspects of the attribute semantics. Say the "xxx" collection attribute has N member attributes named "aaa1", "aaa2", ..., "aaaN" ("aaaI" stands for any one of these N member attributes) 🎀.
- The name of the collection attribute MUST be specified (e.g., "xxx") 🏷️. The choice of the name "xxx" MUST follow the same uniqueness rules as attributes of any other syntax type (as defined by IPP/1.1), unless "xxx" is a member attribute of another collection. Then the choice of the name "xxx" MUST follow the uniqueness rules defined in item 5a) of this list.
- The collection attribute syntax MUST be of type
'collection'or'1setOf collection'🌸. - 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. 🧚
- 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.
- a) "xxx-supported" is a
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" 🍓.
- 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.
- 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") are 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.
- i) If "xxx-supported" is a
- a) The member attribute's name (e.g., "aaa") MUST be unique within the collection being defined and MUST either:
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 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
- 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.
- 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. 🙈
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 or a response. ✨
4.2 Unsupported Values 🚫
The rules for returning an unsupported collection attribute are an extension to the current rules 😭:
- 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.
- 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. 🦋
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 the "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) 🎀
Okay bestie, the media-col (collection) attribute is the glow-up for the IPP/1.1 [RFC2911] media attribute 💅. It lets a client end user send a whole list of media characteristics to the Printer. When the client specifies media using media-col, the Printer object MUST match the requested media exactly. No vibes-based guessing, it's an exact match 🫶. The 'collection' is made up of these 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 MUSTThe member attributes get their full definitions in the sub-sections below 🦋.
5.1.1 media-color (type3 keyword | name(MAX)
This member attribute tells you the color of the media 🌈. Valid values are 'red', 'white' and 'blue'.
The media-color-supported (1setOf (type3 keyword | name(MAX))) Printer attribute tells you which values of this media-color member attribute the Printer supports, which is basically the list of colors it can do 💜.
If the client leaves out this member attribute, the Printer works out the value in an implementation dependent manner 🙈.
5.1.2 media-size (collection)
This member attribute tells you the size of the media 📏. The 'collection' has 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 MUSTThe definitions for these member attributes are in the sub-sections below 🧚:
5.1.2.1 x-dimension (integer(0:MAX))
This attribute tells you the width of the media in inch units along the X axis 📐.
5.1.2.2 y-dimension (integer(0:MAX))
This attribute tells you the height of the media in inch units along the Y axis 📐.
The media-size-supported (1setOf collection) Printer attribute tells you which values of this media-size member attribute the Printer supports, aka the size combinations it can handle 🍓. The member attribute names are the same as the ones on the media-size collection attribute, namely x-dimension and y-dimension, because they have the same attribute syntax and the same semantics. Iconic consistency 👑.
5.2 media-col-default (collection)
The media-col-default Printer attribute says what media the Printer uses, if any, when the client leaves out both media-col and media 🌸. Job Template attributes in the Job Creation operation and the PDL don't include a media specification. The member attributes are defined in Table 1. A Printer MUST support the same member attributes for this default collection attribute as it supports for the matching media-col Job Template attribute. No mismatched defaults, periodt 💅.
5.3 media-col-ready (1setOf collection)
The media-col-ready Printer attribute identifies the media that's available to use without human intervention, so the media that's ready to go with nobody touching anything 🙌. 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 🎀. In other words, the keyword names of the member attributes in Table 1 that the Printer supports.
6 A Second Example Definition Of A Collection Attribute ✨
Okay so, all of the example attribute definitions in this document are illustrative examples, not actual definitions 🫶. They're there to show how to define collection attributes. Other documents MUST define collection attributes for use in actual interchange. The examples might be very similar to what's in this document, since we tried to pick useful ones 💖.
In some printing environments, it's desirable to let the client pick 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. So instead, a new Job Template attribute is introduced, e.g., job-sheet-col (collection) 🌈.
The member attributes of the 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, so they reuse existing IPP attributes 🔥. Under those rules, their supported values come from the existing IPP attributes: job-sheets-supported and media-supported. But their default values do NOT come from job-sheets-default and media-default, respectively. Plot twist 👀. 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.
If the 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)). Its values would be independent of media-supported (1setOf (type3 keyword | name)), and a System Administrator would set them separately 👑.
The actual text for the definition of the attribute is left as an exercise for the reader 📝 (no cap, homework energy).
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 attributeWhen encoding a collection attribute "xxx" that contains an attribute "aaa" and is not inside another collection, the encoding follows these rules 🎀:
- 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) 🌸.
- 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 the 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 💅.
- The end of the collection is indicated with a value tag that MUST be syntax type 'endCollection' (e.g., 0x37), and it 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' 🫶.
- 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' ✨.
- It is valid for a collection attribute to be multi-valued, i.e., to 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) 🎀
okay so 💖 this is where the collection from section 5 finally gets encoded, and it's giving nested collections too, because "media-size" is a collection living inside another collection 🙈 The example is a blue 4x6 index card and it takes 216 octets. The Appendices have more complex examples if you're obsessed (💅).
The big picture of the two collection values looks like this 🧚
"media-col" =
{ "media-color" = 'blue';
"media-size" =
{ "x-dimension" = 6;
"y-dimension" = 4
}
},The full encoding is in Table 5. Before that, here's a simplified view 🍓
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 "" ""Now the real bytes, octet by octet 🔥 Table 5 is a lot, but each row is just one piece of the puzzle, so take it slow bestie 🫶
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)
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"
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
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
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 🦋
okay so the legacy crowd 👑 IPP 1.x Printers and Clients don't crash when they meet a collection they don't understand. They just gracefully ignore it, collection and all its member attributes 🙌 The begCollection and endCollection tags each look like an attribute with a syntax the recipient doesn't support, so it skips the whole thing. The member attributes and their values look like 1setOf values of the collection attribute, so the Printer just ignores the entire attribute and every value with it. Returning it as unsupported is simple too: only the collection's name gets sent back, with the 'unsupported' out-of-band value (see section 4.2). iconic ✨
9. IANA Considerations 🌈
this part is the registration paperwork 📝 The table below registers the 'collection' attribute syntax defined in this document, and the registration follows 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.1The resulting attribute syntax registration gets published in the http://www.iana.org/assignments/ipp-registrations registry 🎀
10. Internationalization Considerations 🌸
this attribute syntax on its own has zero impact on internationalization, ngl 🙈 BUT the member attributes that get defined for a collection later might have internationalization considerations, same as any attribute, according to [RFC2911] 🫶
11. Security Considerations 🔥
this part is serious, bestie 💀 This attribute syntax causes no more security concerns than any other attribute syntax. It's only the attributes defined later, which use this syntax or any other one, that might have security concerns, and those depend on what the attribute means, according to [RFC2911]. so keep an eye on the semantics of whatever you add 👀
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 📚
okay so these are the friends the spec mentions for background, not the must-read homework 🎀 Here's the whole list, exactly as written:
[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.Appendix A: Encoding Example of a Simple Collection (Informative) 🧚
okay, time for the fun part ✨ First, here's the big-picture vibe of the whole collection value, picture-style 💖
"media-size" =
{ "x-dimension" = 6;
"y-dimension" = 4
}Next up is a simplified view of how that gets encoded 🌸
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 🫶
And now the full, octet-by-octet version, the real deal 🔥
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
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)
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)Appendix B: Encoding Example of 1setOf Collection (Informative) 🎀
okay so this one is the big payoff 💅 we're gonna look at what a whole 1setOf collection actually looks like once it's been squished into bytes. first, the big picture, then the bytes, bestie 🫶
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
};ok the vibe is giving two little rectangles 🦋 one is 6 by 4 and the other is 3 by 5. the attribute is called "media-size-supported" and it holds both of them. ✨
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 "" ""Table 8 is the zoomed-out version 🧚 same two rectangles, just with the tags lined up in a row, so you can see the shape before the octets show up.
now the real deal, the full octet-by-octet breakdown 🤓 this is where it gets intense, ngl 😭
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)
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)
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
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
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)ok that's the whole thing, and honestly it's giving main character energy 👑 the first member is 6 by 4, the second is 3 by 5, and every single byte has a job. 💖 the "0x0000" name-length is basically the tell that you're still inside the same 1setOf attribute, so no repeated name needed 🙈 iconic, periodt 💅
Appendix C: Encoding Example of Collection containing 1setOf XXX attribute (Informative) 🎀
okay so this appendix walks through a collection that holds a 1setOf attribute, and it's giving main character energy 💅 first, here's the big picture of the "wagons" collection:
"wagons" =
{ "colors" = red, blue;
"sizes" = 4, 6, 8
}next, a simplified view of how that gets encoded 🧚
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 "" ""and now the real thing, octet by octet 🔥 bestie, this is the part where you get to see every single byte doing its job 🦋
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
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
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
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 these six bestie-approved reads:
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]so the "Design Goals for an Internet Printing Protocol" doc takes a super broad look at distributed printing 🖨️ it walks through real-life scenarios to figure out what a printing protocol for the Internet actually needs, and it spells out requirements for three kinds of users: end users, operators, and administrators. it calls out a subset of the end user requirements that are met in IPP/1.0 [RFC2566, RFC2565], and a few OPTIONAL operator operations were added in IPP/1.1 [RFC2911, RFC2910]. the vibe is very "let's plan before we build" 🌸
the "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" doc gives you the high-level view of IPP ✨ it maps out a roadmap for all the documents that make up the IPP spec suite, and it explains the background and reasoning behind the IETF IPP working group's big decisions. basically the "why did we do it this way" doc, and honestly iconic 🫶
the "Internet Printing Protocol/1.1: Model and Semantics" doc is a simplified model made of abstract objects, their attributes, and their operations 🦋 it introduces a Printer and a Job, and the Job can hold multiple documents. it also covers how security, internationalization, and directory issues get handled 🌈
the "Internet Printing Protocol/1.1: Encoding and Transport" doc is the formal mapping of those abstract operations and attributes from the model doc onto HTTP/1.1 [RFC2616] 🍓 it defines the encoding rules for the new Internet MIME media type called "application/ipp", and the rules for carrying a message body whose Content-Type is "application/ipp" over HTTP. it also defines the 'ipp' scheme for identifying IPP printers and jobs, which is so cute 💜
the "Internet Printing Protocol/1.1: Implementer's Guide" doc is full of insight and advice for anyone building IPP clients or IPP objects 🧚 it's there to help you understand IPP/1.1 and the stuff that can shape how you design your client and/or IPP object implementations. for example, it gives a typical order for processing requests, error checking included, and it explains the motivation behind some of the spec decisions too. very helpful, very slay 💅
and the "Mapping between LPD and IPP Protocols" doc 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
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
okay so if you want to join the ipp mailing list, here's how to subscribe 📮 you 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
endimplementers of this spec are super encouraged to join the IPP Mailing List 🫶 that's where people talk through clarification issues and review registration proposals for new attributes and values. heads up though: to cut down on spam, the list rejects mail from non-subscribers, so you have to subscribe before you can send a question or comment to the list 🙈
Full Copyright Statement 💅✨
Copyright (C) The Internet Society (2002). All Rights Reserved.
okay bestie, this part is all about who owns the words 📜 and what you're allowed to do with them 🫶 Copying this doc and sharing it around is totally fine, and so is writing derivative works that comment on it or explain it or help people build it 🎀. You can make those copies and publish and distribute them, in whole or in part, with zero restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work 💜
Now the spicy part 🌶️ You can't modify this document itself. No removing the copyright notice, no scrubbing out references to the Internet Society or other Internet organizations. The exceptions are: developing Internet standards (in which case the Internet Standards process copyright procedures must be followed, so lowercase "must" here is just the normal sentence, not a BCP 14 keyword 🙈) or translating it into languages other than English 🌍
The permissions are perpetual 🦋 They won't be revoked by the Internet Society or its successors or assigns. Forever means forever, periodt 💖
Also, the whole document and everything in it gets handed over "AS IS" 🤷♀️ and the Internet Society and the Internet Engineering Task Force are not making any promises, express or implied. That includes no guarantee that using the info won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose 💀 Here's the exact disclaimer, because lawyers 🙄
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 🌸
okay last bit, and it's a sweet one 🥹 Funding for the RFC Editor function is currently provided by the Internet Society. So the people keeping the RFC series running get their money from the Internet Society right now 💜 That's the whole thing, bestie, we made it through all 8 parts 🎉👑
📦 where this page comes from
- ietf: rfc3382 2002-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms