A agree with Scott Isaacson that if we get to the point where BER encoding
'makes sense', then IPP is in deep trouble. Perhaps instead of trying to come
up with encoding schemes to handle more and more complexity, we should try to
take a step backwards and make the system simpler. In my experience, complexity
is usually a sign of a bad design.
--- Charles
______________________________ Reply Separator _________________________________
Subject: Re: IPP> PRO - A value-type field for the Protocol Spec
Author: Robert.Herriot@Eng.Sun.COM (Robert Herriot) at Internet
Date: 6/9/97 12:09 PM
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@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@pwg.org
> 06/06/97 08:17 PM
> Please respond to rturner@sharplabs.com @ internet
>
>
> To: ipp@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@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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>