IPP> Encoding

IPP> Encoding

IPP> Encoding

Brian Grimshaw brian at apple.com
Fri Jun 20 17:06:27 EDT 1997


Bob,


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 at 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?
>> 



More information about the Ipp mailing list