Summary

  • RFC 3382 added an optional IPP collection syntax for keeping heterogeneous named members inside one value, including nested collections and future optional members.
  • The order of those members was explicitly non-authoritative. A Printer could return them in another order, so meaning had to remain attached to unique names and collection boundaries rather than byte position.

A client sends a collection with three members. The Printer returns the same three members, but the first has become the third and the third has become the second. If the client has treated position as identity, the exchange appears corrupted. Under RFC 3382, the Printer may have done exactly what the protocol allowed. The stable facts are the member names, their syntaxes, their values and the boundary that says they belong together.

Published in September 2002 on the Standards Track, RFC 3382 filled a structural gap in the Internet Printing Protocol. IPP already had syntax for many familiar scalar and repeated values, but it lacked a general way to group attributes of different types as one value. The RFC compared its new construct to a PostScript dictionary or a Java Map. The comparison was about named membership, not about importing an entire programming-language object model into IPP.

The need sounds mundane: describe one thing with several related fields. A physical medium, for example, might need dimensions, type, colour or source information to travel as one conceptual unit. A flat list can carry each fact, but it becomes difficult to say which values belong to which instance when several such units appear. A collection supplied that boundary.

RFC 3382 defined a collection as one or more member attributes. Each member had a name and its own syntax. One could be an integer, another a keyword, another a range, and another could itself be a collection or a set of collections. The outer container did not erase these types. It let unlike values remain distinct while declaring that they participated in one structure.

That grouping did not produce a sequence contract. The RFC said member attributes could occur in any order. A Printer could store them internally and return them in an order different from the request. This was not a minor serialization footnote. It decided where semantic authority lived. A consumer had to resolve a member by name, not by saying that the second value always meant height or that the last value always meant colour.

Names therefore carried a heavier burden. A document defining a real collection attribute had to specify the collection's name, whether it was single- or multi-valued, the contexts in which it could appear, how supported members were advertised, each member name, requirement level, syntax, semantics, constraints, supported values and defaults. The container syntax created a place for structure; it did not excuse the specification from defining that structure.

Member names had to be unique within one collection definition. The same name could legitimately appear in another collection or elsewhere in the broader IPP attribute namespace, because the collection boundary supplied scope. This is the useful asymmetry: uniqueness was local enough to allow reuse, yet strict enough inside one container to make name-based lookup unambiguous.

A collection value containing the same member name twice was malformed. Clients were not to send it, and Printers were not to return it. The receiver's permitted behaviour also exposed an important limit. A Printer could reject the request as bad, or it could accept the request and use only one of the duplicates, depending on implementation. RFC 3382 did not establish a portable first-wins or last-wins rule. Once uniqueness failed, serialized order could not safely repair the meaning.

That boundary matters for security and operations as much as for parsing. If two components choose different duplicates, validation can occur against one value while execution uses another. The RFC did not describe that modern attack pattern, and publication alone says nothing about a particular product. But its conformance rule points in the right direction: producers should not create ambiguity, and consumers should not invent a position rule that the protocol never promised.

Nesting made the model more expressive. A member could contain another collection, and a member could be a set of collections. There was no single global length limit for the collection as a whole, although every member remained constrained by its own syntax. The result was not an unbounded free-form document. It was a recursive structure whose leaves still followed IPP value rules and whose definitions still had to enumerate the supported grammar.

Extension was equally deliberate. A collection definition could include optional members, and later documents could add further optional members where the defining rules allowed it. An older implementation did not need to pretend that it understood a new member. It needed a disciplined way to identify what was unsupported while keeping the failure tied to the correct container.

RFC 3382 did this through the Unsupported Attributes Group. When members were unsupported or conflicted, they could be returned inside a collection, preserving the boundary around what failed. Flattening the member into an unrelated top-level error would lose context. The same name could exist in several scopes; the surrounding collection explained which use had caused the problem.

The wire encoding reinforced those boundaries. begin-collection, member-name and end-collection tags framed the structure. The design took older IPP parsers into account so that a parser unfamiliar with collections would not casually treat a member name as an ordinary top-level attribute. Compatibility here did not mean that a legacy implementation suddenly understood the new semantics. It meant the extension was framed so ignorance would be less likely to become misinterpretation.

The RFC's media-col and job-sheet-col material was illustrative. It showed how authors might define collections, including required and optional members, supported-member attributes and nesting. It did not by itself standardize those examples as deployed attributes. A subsequent specification still had to perform the definitional work. Copying an example name into a payload did not create an interoperable contract.

This point separates RFC 3382 from the two IPP extensions immediately beside it. RFC 3380 concerned the atomic acceptance or rejection of a job-attribute update. RFC 3381 concerned progress counters whose interpretation changed with collation and observation boundaries. RFC 3382 asked a more basic representational question: how could several typed values travel as one unit without making their physical order part of their meaning?

The answer updated both RFC 2910, the IPP/1.1 encoding and transport document, and RFC 2911, the model and semantics document. Earlier RFC 2565 and RFC 2566 had defined the IPP/1.0 counterparts; RFC 2567 recorded requirements, and RFC 2568 explained design goals and protocol structure. Later RFC 8010 and RFC 8011 consolidated the encoding and model. That chronology locates the mechanism. It does not prove adoption, product behaviour or successful printing.

The separation between membership and order is durable because many systems accidentally make presentation carry identity. A decoder reads fields into an array, an application renders that array, and soon the third element has acquired a meaning that no specification assigned. The arrangement works until a serializer normalizes its output, a new optional member is inserted, or an intermediary reconstructs the collection from a map.

RFC 3382's rule interrupts that drift. If order may change, then tests must shuffle it. If names define members, then duplicate names must be rejected or quarantined as ambiguity. If nesting supplies scope, then logs and error reports must preserve the path into the nested collection. If optional extension is allowed, an unknown member must remain visibly unknown rather than being silently bound to the nearest familiar position.

Lu Heng's minimum-initial-specification lens helps explain the design economy. The RFC did not try to standardize every future structured attribute. It standardized the smallest reusable container, the duties of documents that defined concrete collections, and the rules that let optional members appear without rewriting the base model. Future decisions stayed localized in new definitions.

His reality-layers lens supplies the corresponding warning. Serialized order is one presentation layer. Member identity, collection membership, support status, validated meaning and eventual device action are different layers. A cleanly decoded collection does not prove that every member was supported, that a request was accepted, or that a physical operation succeeded. The grouping syntax is evidence about structure, not a certificate of outcome.

The historical achievement of RFC 3382 was therefore not that it put brackets around a few values. It taught IPP to preserve a relationship while permitting representation to move. The collection kept its members together. Unique names and explicit boundaries kept those members intelligible. Order was allowed to remain what it should have been all along: an incidental property of one encoding.

Sources