rfc-3382

Internet Printing Protocol (IPP): The 'collection' attribute syntax

R. deBry, T. Hastings, R. Herriot, K. Ocke, P. Zehler
date2002-10 streamIETF areaapp wgipp statusPROPOSED STANDARD pages38 canonicalhttps://www.rfc-editor.org/rfc/rfc3382 doi10.17487/RFC3382 errataview
This document specifies an OPTIONAL attribute syntax called 'collection' for use with the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566], IPP/1.1 [RFC2911, RFC2910]. A 'collection' is a container holding one or more named values, which are called 'member' attributes.

obsoleted by

updates

Extracted elements (25)

design-rationale §5

Rather than extending the existing 'media' attribute syntax to include 'collection', a new attribute ('media-col') MUST be added to preserve interoperability. Existing clients that do not support the collection syntax could not understand default or supported media values that use the collection value if the existing 'media' attribute were extended.

design-rationale §7.1

The collection is encoded as a 1setOf to make it easy for a Printer that does not support a particular collection attribute (or the collection attribute syntax at all) to simply skip over the entire collection value, ensuring backward compatibility with IPP 1.x parsers.

design-rationale §1.1

The 'collection' mechanism was designed to be encoded consistently with existing IPP 1.0 and 1.1 parsing rules so that current parsers that do not support collections will not confuse collections or parts of a collection with other attributes.

interoperability-note §8

IPP 1.x Printers and Clients will gracefully ignore collections and their member attributes if they do not understand the collection syntax. The begCollection and endCollection elements each look like an attribute with an unsupported attribute syntax, causing the recipient to ignore the entire attribute and all its values.

normative-requirement §1.2 MUST NOT

A collection value MUST NOT contain two or more member attributes with the same attribute name. Clients MUST NOT submit such malformed requests and Printers MUST NOT return such malformed responses. If such a malformed request is submitted, the Printer MUST either reject it with 'client-error-bad-request' or accept and use only one of each duplicate member attribute.

normative-requirement §5.2 MUST

A Printer MUST support the same member attributes for the 'media-col-default' collection attribute as it supports for the corresponding 'media-col' Job Template attribute.

normative-requirement §3.1 MUST

An 'xxx-supported' attribute MUST be specified for every collection attribute, in one of two forms: (a) a '1setOf collection' enumerating all supported collection values, or (b) a '1setOf type2 keyword' enumerating the names of all member attributes.

normative-requirement §1.2 MUST

If a collection 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.

normative-requirement §7.1 MUST

The beginning of a collection MUST use a value tag of 'begCollection' (0x34); the end of a collection MUST use a value tag of 'endCollection' (0x37). The Printer MAY ignore the value of the begCollection and its length MAY be 0.

normative-requirement §7 MUST

The encoding tags defined in this document (begCollection, endCollection, memberAttrName) MUST be used by all collection attributes defined in other documents.

normative-requirement §1.2 MUST

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.

normative-requirement §3.1 MUST

When a specification document defines a collection attribute, the definition MUST include: the name of the collection attribute, the collection attribute syntax (collection or 1setOf collection), the context of the attribute, an 'xxx-supported' attribute, and the member attributes with their names, optionality, syntax types, semantics, supported values, and defaults.

normative-requirement §5.1 MUST

When the client specifies media using the 'media-col' collection attribute, the Printer object MUST match the requested media exactly.

protocol-element §1.2

The 'collection' attribute syntax is a container holding one or more named values called member attributes. Each collection value is a value of an attribute whose attribute syntax type is defined to be 'collection'. The name of the collection attribute identifies the collection value in an operation request or response.

registry

protocol-element §5.1

The 'media-col (collection)' attribute is an example collection that enables a client to select media by properties (color, size) rather than name. It contains member attributes 'media-color (type3 keyword | name(MAX))' (optional for client, MUST be supported by Printer) and 'media-size (collection)' (MUST for both client and Printer).

protocol-element §5.3

The 'media-col-ready (1setOf collection)' Printer attribute identifies media available for use without human intervention. The collection value MUST have all of the member attributes that are supported.

protocol-element §5.4

The 'media-col-supported (1setOf type2 keyword)' Printer attribute identifies the keyword names of the member attributes supported in the 'media-col' collection Job Template attribute.

protocol-element §5.1.2

The 'media-size (collection)' nested collection contains two REQUIRED member attributes: 'x-dimension (integer(0:MAX))' identifying the media width, and 'y-dimension (integer(0:MAX))' identifying the media height.

protocol-element §4.2

Unsupported collection attribute handling: if the entire collection attribute is unsupported, the Printer returns just the collection attribute name with the 'unsupported' out-of-band value. If a collection contains unrecognized or unsupported member attributes, the Printer returns a collection in the Unsupported Group containing those unrecognized/unsupported member attributes with their unsupported values.

registry §9

This document registers the 'collection' attribute syntax and three encoding tags with IANA in the IPP attribute syntaxes registry: collection (no tag), begCollection (0x34), endCollection (0x37), and memberAttrName (0x4A), per procedures in RFC 2911 section 6.3.

registry

security-consideration §11

The 'collection' attribute syntax causes no more security concerns than any other attribute syntax. Security considerations depend on the semantics of the member attributes subsequently defined to use this syntax, as governed by RFC 2911.

security

wire-format §7.1

A collection is encoded using begCollection (0x34) with the collection attribute name and a zero-length value, followed by pairs of memberAttrName (0x4A) values (holding member attribute names) and the member attribute values, terminated by endCollection (0x37) with zero name and value lengths.

wire-format §7.1

For a multi-valued (1setOf) collection attribute, each additional collection value begins with a begCollection tag with zero name-length immediately following the previous endCollection. Nested collections are represented by a memberAttrName followed by a begCollection tag with zero name-length, terminated by a matching endCollection.

wire-format §7.1

The begCollection tag includes the attribute name field (with nonzero name-length) and a zero-length value field. The memberAttrName tag always has a zero name-length (making it part of a 1setOf sequence) and its value field contains the name of the member attribute.

wire-format §7.1

Three encoding tags are defined for the 'collection' attribute syntax: begCollection (0x34) marks the beginning of a collection value; endCollection (0x37) marks the end; memberAttrName (0x4A) carries the name of a collection member attribute as its value.