I do not see anything new in this post June 17 discussion -- just a
repeat of previous issues and opinions. What I've extracted from the
recent mail is:
1) Parsing text encoding difficult and error prone.
- ascii to binary conversion
- string compares to interpret attribute names
I don't see text encoding as difficult or risky. Any product I'm
planning IPP support for already does these things.
2) Text encoding has no apparent benefit.
I think this is just an opinion that the text encoding benefits offered
are not compelling to everyone. In itself, this is not a benefit of
binary encoding.
3) Text encoding makes for easier client/server debug.
I agree that this is a --small-- benefit.
4) Text based encoding leverages tools of HTTP solutions.
I think this is a fairly neutral statement. It simply justifies the
position that handling ascii encoding is not difficult nor uncommon.
And from June 17:
5) No endian issues with text encoding.
I see this as another --small-- benefit.
I would add to the list:
6) Text encoding of attributes simplifies management of
extensions -- both vendor extensions and future IPP versions.
This eliminates the maintenance of a mapping of names to numbers.
Unless there is a problem caused by text encoding, which I do not see, I
prefer it and the associated few benefits.
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?
Brian
--------------------
Brian Grimshaw
Apple Computer, Inc.
brian@apple.com