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

Randy Turner rturner at sharplabs.com
Fri Jun 6 17:44:40 EDT 1997


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



More information about the Ipp mailing list