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

From: Scott Isaacson <[email-masked]>
Date: Fri, 06 Jun 1997 13:06:37 -0600

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 <[email-masked]> 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

---

From: Brian Grimshaw <[email-masked]>
Date: Fri, 6 Jun 97 13:10:02 -0700

I agree with Scott...

>...

...and have an additional observation.

I admit I do not know the details of ASN.1 and BER, but are these not 
just formal mechanisms for describing data objects and how they are to be 
encoded?

What Steve suggested was to define type keywords/codes and include them 
in the data exchanged between IPP client and server, such that the 
attribute name/value pairs become name/type/value triplets.  This allows 
for various parsing options that WOULD OTHERWISE require a "dictionary" 
for all the objects (like that provided by a compiled MIB).

I do not see this as reinventing ASN.1 and I do not see how ASN.1 would 
meet Steve's goal.

Brian

>reinvent another way to do this.

Brian Grimshaw
Apple Computer, Inc.
[email-masked]

---

From: Randy Turner <[email-masked]>
Date: 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

---

From: Scott Isaacson <[email-masked]>
Date: Fri, 06 Jun 1997 16:21:35 -0600

Randy,

Yes, let's just stick with ABNF.

>>> Randy Turner <[email-masked]> 06/06 3:44 PM >>>
> If we are mixing binary and ASCII values within our encoding ...

See my earlier posting measurements we did of our prototype where
we encoded both ways 
"(binary length)name(binary length)value"
and then just
"name:valueCRLF"
Not a lot of difference in our timing measurements.  In fact it takes more
time to encode using binary lengths.

Doesn't seem worth it to me to skip a great legacy and ease extensibility
and
reduce risk of interoperability for almost no processing gain on a 
portion that is only very minimally involved in the overall end-to-end
processing
time required from application-to-paper.

Scott

---

From: Harry Lewis <[email-masked]>
Date: Mon, 9 Jun 1997 11:04:53 -0400

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

        [email-masked]
        06/06/97 08:17 PM
Please respond to [email-masked] @ internet

To: [email-masked] @ internet
cc:
Subject: Re: IPP> PRO - A value-type field for the Protocol Spec

Randy

---

From: [email-masked] (Robert Herriot)
Date: Mon, 9 Jun 1997 12:09:35 -0700

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 [email-masked] Mon Jun  9 08:16:39 1997
>

---

From: [email-masked] (Charles Gordon)
Date: Mon, 9 Jun 1997 16:35:32 -0400

ASN.1 and BER are designed to handle any conceivable data type.  However, that 
flexibility comes at a high price.  I have happen to have been working on code 
to encode and decode SNMP packets the last few weeks.  So, I can tell you from 
personal experience that BER encoding is very inefficient and also more than a 
little bit complex.  I doubt that we really need to use BER for the stuff we are
doing with IPP.  As someone who is actually writing code that deals with BER, 
IMHO BER is not worth the price in complexity (bugs).  

A agree with Scott Isaacson that if we get to the point where BER encoding 
'makes sense', then IPP is in deep trouble.  Perhaps instead of trying to come 
up with encoding schemes to handle more and more complexity, we should try to 
take a step backwards and make the system simpler.  In my experience, complexity
is usually a sign of a bad design.

                                        --- Charles

______________________________ Reply Separator _________________________________
Subject: Re: IPP> PRO - A value-type field for the Protocol Spec
Author:  [email-masked] (Robert Herriot) at Internet
Date:    6/9/97 12:09 PM

Bob Herriot

---

From: Tom Hastings <[email-masked]>
Date: Mon, 16 Jun 1997 22:58:46 PDT

SNMP uses a very simple subset of ASN.1/BER, so that SNMP implementation
is no where near as complex as general ASN.1/BER.

Tom