SNMP uses a very simple subset of ASN.1/BER, so that SNMP implementation
is no where near as complex as general ASN.1/BER.
Tom
At 12:09 06/09/97 PDT, Robert Herriot wrote:
>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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>>>>>>>>>>>>>