IPP Mail Archive: Re: IPP> PRO - A value-type field for the Protocol Spec

Re: IPP> PRO - A value-type field for the Protocol Spec

Randy Turner (rturner@sharplabs.com)
Fri, 06 Jun 1997 14:44:40 -0700

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"??
>
> 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.
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>