Part of the reaction is the ASN.1/BER is far more complex than simple
text or XDR. In addition, DPA implementations use full ASN.1/BER and
the BER libraries have made significant contributions to their very large
size. I don't know how much BER contributes to the size of SNMP
implementations, but SNMP uses a subset of BER.
Bob Herriot
> From harryl at us.ibm.com Mon Jun 9 08:16:39 1997
>> I vote to keep IPP simple, but disagree that ASN.1 is a culprit.
>> > 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.
>> The IETF Printer MIB has the support of 9 or 10 vendors, today, with
> software on many diverse platforms and in 6 or 7 vendors embedded
> controller product lines. I keep hearing we shouldn't "strangle" IPP
> with embedded controller limitations. How then, can we claim ASN.1/BER
> is too "heavy" for IPP?
>> I find lack of compatibility with existing IETF standards (the debate
> over "x,y resolution" for example), and the resulting redundancy, one
> of the "heaviest" things about IPP.
>>> >>> Harry Lewis <<<
>>> --------- Forwarded by Harry Lewis/Boulder/IBM on 06/09/97 08:28 AM ---------
>>ipp-owner at pwg.org> 06/06/97 08:17 PM
> Please respond to rturner at sharplabs.com @ internet
>>> To: ipp at pwg.org @ internet
> cc:
> Subject: Re: IPP> PRO - A value-type field for the Protocol Spec
>> If we are mixing binary and ASCII values within our encoding and require
> extensibility with regard to
> names, types, and values, then this is the kind of thing ASN.1/BER was
> designed for. I suggested
> that we just stick with ABNF as our specification and I would have been
> happy with that. However,
> when we're talking about a more complete, extensible, protocol, in which
> registries come into play,
> I think ASN.1/BER would be a better solution. It adapts much better to
> varying length TLV
> (type, length, value) pair operations and allows implementations (later
> versions) of a protocol to
> adapt easier. (i.e., no version eschange or negotiation).
>> Randy
>> Scott Isaacson wrote:
>> > 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"??
> >
>> >
> > Much of the discussion recently has been around "simplicity". Has
> > IPP lost it ability to be simple? No, I don't think it has. Is it
> > too
> > convoluted in some areas - YES.
> >
> > There was a discussion a few weeks ago about whether IPP was DPA '97.
> > This
> > reminder was a good wake-up call, and useful in that there seemed to
> > be
> > immediate consensus that IPP is not intended to be too complex like
> > DPA is
> > considered to be.
> >
> > I vote keep it simple. Add value-types only if it is a value or
> > keyword
> > that represents a specific well know syntax as described in the
> > standard
> > (extensible through registration). But don't add arbitrarily
> > extsensible,
> > compound data structures as potential values. And don't use ASN.1 !!
> >
> > Scott
> >
> > >>> 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>>>>>>