IPP> PRO - A value-type field for the Protocol Spec

IPP> PRO - A value-type field for the Protocol Spec

IPP> PRO - A value-type field for the Protocol Spec

Brian Grimshaw brian at apple.com
Fri Jun 6 16:10:02 EDT 1997


I agree with Scott...


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



More information about the Ipp mailing list