Bob,
I think that we are in agreement that there are at least three ways
that the current encoding could be used to represent an attribute
whose value(s) are attributes. None of these approaches would require
any change to the current encoding scheme. Such attributes could
be regestered after V1.0 is a proposed standard, even though the new
attribute has a new data type that is not in V1.0. The key is that
we have agreed to a general mechanism using a *length* to represent
an attribute value. The contents of the value are opaque to any recipient
that doesn't recognize and support the attribute as indentified by the
attribute-name. Any recipient (Printer receiving a request or client
receiving a response) that doesn't understand that new attribute at least
knows how to skip over the value (or values if the attribute has multiple
values) in order to examine the next attribute. [BTW - we need some
conformance requirement that requires recipients (Printers and clients)
to skip over attributes they don't understand, rather than erroring out.]
This mail message shows the importance of keeping the length mechanism
in our encoding approach in order to achieve future extensibility
with no impact on V1.0.
The three ways are (each with a new data type):
1. A multi-valued data type with each value representing an attribute and a
value
2. A multi-valued data type with each value representing a set of attributes
3. A multi-valued data type with each pair of values representing
the attribute name and the attribute value (your suggestion).
The example encodings of each of the three methods is as follows
for the case of an "address" attribute whose value consists of OPTIONAL
attributes: "name", "apartment-number", "street", "city", "state", "zip",
"country":
Method 1: the new data type that is a *single* attribute (name and value).
When such an attribute has multiple attributes as values, use the multi-valued
mechanism of IPP, one value for each attribute. In this approach, each
(sub-)attribute can only be single-valued.
"address 15 name 8 John Doe 17 street 8 123 Main 9 city 2 LA 10 state 2 CA"
Method 2: the new data type is a *set* of attributes.
In the above example, the value of the "address" is single valued.
But it could be multi-values, providing multiple addesses.
"address 52 name 8 John Doestreet 8 123 Maincity 2 LA state 2 CA"
Method 3: the new data type is pairs of attribute-name attribuet-value
The attribute-value must be single-valued (same restriction as method 1).
"address 4 name 8 John Doe 6 street 8 123 Main 4 city 2 LA 5 state 2 CA"
Method 3 is perhaps the easiest to parse.
Tom
At 18:57 06/20/97 PDT, Robert Herriot wrote:
>I think what you and Brian are trying to define is a set of values where
>each value has a name associated with it.
>>As long these names are fixed, this is just a new data type with implicit
>names associated with each member of the set.
>>Since we have said that a client either has this information hardwired
>(version 1) or can get typing information from a server ( a later version),
>there is no need for the parameter representation to store the names
>of individual members. This problem is much like the compiling of
>a C struct.
>>If you are looking for an attribute to contain a list of attributes
>where the name is unknown in advance and where each is single valued,
>then there could be a datatype which is a set of 2-tuple where each
>2-tuple is a name and a value. We talked about this solution for a set
>of integer ranges. The hard case is for attributes that are
>multivalued.
>>The point of all this is that our current protocol representation for
>sets gives use a 95% solution and that is simple and good enough for now.
>>Bob Herriot
>>>> From hastings at cp10.es.xerox.com Fri Jun 20 18:39:13 1997
>>>> At 12:50 06/20/97 PDT, Brian Grimshaw wrote:
>>>> An example of an "address" attribute whose value consists of attributes:
>> "name", "apartment-number", "street", "city", "state", "zip", "country"
>> would be in ABNF:
>>>> "address 15 name 8 John Doe 17 street 8 123 Main 9 city 2 LA 10 state 2 CA"
>>>>>>>