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