>I am sure that ASN.1 does NOT stand for "A Simple Notation One"?? ;-)
>And BER, wasn't that "Binary Encoding for computing Resource consumption"??
>
>ASN.1/BER is way too heavy for IPP. If we are too close to reinventing
>ASN.1
>then we are way too heavy for IPP.
>...
>
>Scott
...and have an additional observation.
I admit I do not know the details of ASN.1 and BER, but are these not
just formal mechanisms for describing data objects and how they are to be
encoded?
What Steve suggested was to define type keywords/codes and include them
in the data exchanged between IPP client and server, such that the
attribute name/value pairs become name/type/value triplets. This allows
for various parsing options that WOULD OTHERWISE require a "dictionary"
for all the objects (like that provided by a compiled MIB).
I do not see this as reinventing ASN.1 and I do not see how ASN.1 would
meet Steve's goal.
Brian
>>>> Randy Turner <rturner@sharplabs.com> 06/06 12:38 PM >>>
>Prior to the San Diego meeting, I proposed using ASN.1 as a way to
>specify the protocol. This was
>to prevent us from having to "re-invent" the wheel with regards to our
>protocol specification. The nice
>thing about ASN.1 (and its companion BER) is that extensibility is
>easily achieved and with more
>flexibility than what has been proposed so far. I think Larry Masinter
>brought up the fact that ASN.1
>might be a better approach, and if extensibility and clarity of
>specification is what is driving these
>recent discussions, then I'm curious why we are striving so hard to
>reinvent another way to do this.
>
>Randy
Brian Grimshaw
Apple Computer, Inc.
brian@apple.com