I think I was unclear in my question. The proposed protocol allows for
multiple values to be associated with an attribute (as in your finishings
example) which is, indeed, a "set". I am asking for the ability to
represent a grouping of attributes, as in a much earlier example of two
addresses, like "job owner address" and "delivery address". Another
example may be grouping of communications parameters.
If a server knows these attributes, that's OK -- it then knows to parse
the opaque value as an ipp-attribute set. If it doesn't know the
attribute, then it's unable to parse the "contained" attributes --
street, city, zip, etc.
I'm looking for this capability without the explicit encoding of types
and without requiring the parser to know all the attributes. I think
this is much simpler than a complete solution to type encoding and, while
types COULD be leveraged to solve this problem, they are primarily an
orthogonal concept.
Brian
>Sets of n values are represented by a sequence of parameters whose
>parameter name is omitted for parameters 2 through n.
>
>In the example in the minutes:
>
> "0100Print-Job" CRLF
> "job-name 3 foocopies 1 2document-format 22 application/postscript"
> "finishings 5 staple 5 punch" CRLF
> "%!PS
>
>finishings is a set consisting of "staple" and "punch".
>
>I hope this example helps.
>
>Bob Herriot
>
>> From brian@apple.com Fri Jun 20 12:58:19 1997
>> I am more concerned that the proposed protocol (whether binary or text
>> encoded) does not seem to allow representing a set of attributes, or a
>> hierarchy of attributes -- without a parser having knowledge of all
>> attributes. While encoding the type in the protocol has been raised as a
>> solution to this, I think types do not model sets very well and this
>> should be treated as a separate issue. This could be handled in the
>> protocol and, minimally, there should an accommodation for future
>> extensions that may allow this without breaking parsers of IPP 1.0.
>>
>> If I am wrong about this, can someone tell me how to do it with the
>> proposed protocol or where in the various documents this is described?
>>