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