IPP> Encoding

[Tom Hastings]

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 at apple.com
>
>