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

Robert Herriot Robert.Herriot at Eng.Sun.COM
Mon Jun 9 15:09:35 EDT 1997


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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 



More information about the Ipp mailing list