IPP Mail Archive: Re: IPP> Encoding

Re: IPP> Encoding

Tom Hastings (hastings@cp10.es.xerox.com)
Fri, 20 Jun 1997 18:28:13 PDT

At 12:50 06/20/97 PDT, Brian Grimshaw wrote:
snip...

>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.

I'm not exactly sure what you mean by a set.

If you mean a set of values of the same type, then the current
multi-valued encoding works just fine for a set.

In the example in the minutes, there were a set of 2 values for the
"finishing" attribute:

The following is an example of a Print-Job request
"0100Print-Job" CRLF
"job-name 3 foocopies 1 2document-format 22 application/postscript"
"finishings 5 staple 5 punch" CRLF
"%!PS" ...

If you mean a set of attributes then that is another matter. One way
to handle a set of attributes is to have a 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.

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"

A second approach is to define the new data type as 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"

With either scheme in order to group a set of attributes, you need to
define an attribute with the new data type. But since Printer MUST
reject any attribute that they don't understand, a client can only
successfully submit a new attribute with a new data type to a Printer
that supports the new data type.

Is this what you mean by a set? If so, I think we can have sets
in the future with the current encoding and extensibility rules.

Tom

>
>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?
>
>Brian
>
>
>--------------------
>Brian Grimshaw
>Apple Computer, Inc.
>brian@apple.com
>
>