Hi Bob,
To the extent that I understand the encoding alternatives,
I also favor solution #2 (collection as 1setOf values).
Cheers,
- Ira McDonald
-----Original Message-----
From: Herriot, Robert [mailto:Robert.Herriot at pahv.xerox.com]
Sent: Thursday, March 09, 2000 2:38 PM
To: ipp at pwg.org
Subject: IPP>COL encoding issues for collections
The following discusses the issue of encoding collections. I favor solution
#2, but I present 3 solutions: 1a, 1b and 2. I also show 3 examples of each
encoding and discuss their pros and cons. I hope that others will read this
and comment -- perhaps adding additional pros and cons.
The examples illustrate the cases of nested collections, 1setOf collections,
and collections with 1setOf values.
-----------------------
We are now down to considering two encodings for collections. The goals of
the encoding are:
a) must be simple
b) a legacy receiver must correctly ignore a collection value and not
incorrectly decode part of a collection as a legitimate attribute.
c) it parses an attributes with collection values as a single unknown
attribute rather than as many unknown attributes.
The two encodings are:
1) encode attributes within collections in the same way as attributes
outside of collections, but encode each attribute name in a collection so
that its name cannot be the same as an attribute name outside of a
collection. We have considered two solutions for encoding attribute names.
a) add a prefix to each collection member attribute name where the prefix is
the (outer) attribute's name following bya dot ("."). Nested collections
have extra levels of dotted names. For example, the "media-size" attribute
in "media-col" is encoded as "media-col.media-size" and the "x" attribute in
"media-size" which is inside "media" is encoded as "media-col.media-size.x".
The outer attribute name is the "name" of the begin-collecction and
end-collection value.
b) add a hyphen suffix to each attribute name in a collection. For example,
the "media-size" attribute in "media-col" is encoded as "media-size-" and
the "x" attribute in "media-size" which is inside "media" is encoded as
"x-". Note the hyphen must be a suffix so that the attribute name follows
the rules for a legal keyword, and the hyphen is chosen because no
attributes currently end with a hyphen. The empty name is used for the
end-collection value and all but the first begin-collection value.
2) encode attributes within a collection as a 1setOf values where each
attribute whose name is M and whose values are V1 ... Vn are encoded as a a
sequence of n+1 values M, V1, ... Vn. Subsequent member attributes continue
the value in the 1setOf values.
The following are examples of encodings. In the real encoding, each
"attribute" consists of
a) a one byte tag
b) a two byte name length whose value is "n"
c) "n" bytes of a name
d) a two bytes value length whose value is "v"
e) "v" bytes of a value
To make it easy to read, I show only items c (the name), a (the tag) and e
(the value), in that order.
There are 3 encoding examples for each solution:
i) media-col with media-color and media-size as member attributes, and
where media-size contains "x" and "y" as collection members.
ii) media-size-supported with two collection values.
iii) job-notify with notify-recipients and notify-events which is a
1setOf keyword with 3 values in this example
Solution 1a)
Name syntax-type
value
"media-col" begin-collection ""
"media-col.media-color" keyword white
"media-col.media-size" begin-collection ""
"media-col.media-size.x" integer 850
"media-col.media-size.y" integer 1100
"media-col.media-size" end-collection ""
"media-col" end-collection ""
Name syntax-type value
"media-size-supported" begin-collection ""
"media-size-supported.x" integer 850
"media-size-supported.y" integer 1100
"media-size-supported" end-collection ""
"media-size-supported" begin-collection ""
"media-size-supported.x" integer 850
"media-size-supported.y" integer 1400
"media-size-supported" end-collection ""
Name syntax-type value
"job-notify" begin-collection ""
"job-notify.notify-recipients" url
"mailto://bill@foo.com"
"job-notify.notify-events" keyword
job-completed
"" keyword
job-created
"" keyword
job-state-changed
"job-notify" end-collection ""
Solution 1b)
Name syntax-type
value
"media-col" begin-collection ""
"media-color-" keyword
white
"media-size-" begin-collection ""
"x-" integer
850
"y-" integer
1100
"media-size-" end-collection ""
"" end-collection
""
Name syntax-type value
"media-size-supported" begin-collection ""
"x-" integer
850
"y-" integer
1100
"" end-collection
""
"" begin-collection
""
"x-" integer 850
"y-" integer 1400
"" end-collection
""
Name syntax-type value
"job-notify" begin-collection ""
"notify-recipients-" url
"mailto://bill@foo.com"
"notify-events-" keyword
"job-completed"
"" keyword
"job-created"
"" keyword
"job-state-changed"
"job-notify" end-collection ""
Solution 2) Note that the empty name for all but the first attributes is the
"1 setOf value" encoding. All examples for this solution appear as "1 setOf
value"
Name syntax-type
value
"media-col" begin-collection ""
"" attribute-name
"media-color"
"" keyword
white
"" attribute-name
"media-size"
"" begin-collection
""
"" attribute-name
"x"
"" integer
850
"" attribute-name
"y"
"" integer
1100
"" end-collection
""
"" end-collection
""
Name syntax-type value
"media-size-supported" begin-collection ""
"" attribute-name
"x"
"" integer
850
"" attribute-name
"y"
"" integer
1100
"" end-collection
""
"" begin-collection
""
"" attribute-name
"x"
"" integer
850
"" attribute-name
"y"
"" integer
1400
"" end-collection
""
Name syntax-type value
"job-notify" begin-collection ""
"" attribute-name
"notify-recipients"
"" url
"mailto://bill@foo.com"
"" attribute-name
"notify-events"
"" keyword
"job-completed"
"" keyword
"job-created"
"" keyword
"job-state-changed"
"" end-collection ""
Observations:
Solution 1a have identical properties to solution 1b except that the rules
for encoding the name are more complicated for 1a, and the name of the
attribute appears before each end-collection and end-collection in 1a but
only before the first begin-collection in 1b.
If a collection aware client sends a collection to a collection-unaware
Printer:
for solutions 1a and 1b) the collection-unaware Printer sees many
attributes in place of the collection and it returns in the Unsupported
attribute group, all of the attributes: the attribute outside the collection
and each attribute in the collection with its altered name. Thus the
unsupported attributes have names that the client didn't send and they may
be in an order that makes it hard to reconstruct the collection. In
addition, because the "end-collection" has the same name as the attribute
for 1a, some printers will reject the job because the attribute appears
twice. Also, 1a does not work for a 1setOf collection with collection aware
Printers because the name of the attributes appear in front of each
begin-collection and thus cannot be distinguished from two occurrences of
the same attribute.
for solution 2) the collection-unaware Printer sees the collection as a
1setOf values where some values have unknown syntax types and other values
have known syntax types. When a collection-unaware printer discovers it
doesn't understand an attribute that is a collection, it sees the unknown
attribute as a 1setOf rather than a collection. It then returns the
attribute-name with the out-of-band value "unsupported" making it easier for
the client.