[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: going back to stone axes

At 15:41 2/28/96, Bancroft Scott wrote:

>You are diving down to the bits and bytes again.  There is no need to. 

There *is* a need to.

>you keep in mind that SEQUENCE equates to a C struct, SEQUENCE OF equates
>to a linked list or array, and CHOICE equates to a union with a 
>discriminant, and use subtype constraints where possible there is little
>to concern yourself about.  

I keep those in mind.  I know how to write in ASN.1.  Rule 1: don't

It's other people who don't know how to write in ASN.1.  They *do* use
those constructs.

As I said in an earlier message, if your native implementation language
is LISP, SEQUENCE-OF is a natural.  If you're programming in C, it is
unpleasant.  If you have multiple ways to express something -- and one of them
is good for C, then that's the one that should be used as long as C is the
dominant language.

[and, no, I'm not a lover of C -- just a realist]

 - Carl
From ???@??? Wed Feb 28 17:43:00 1996
To: "marcus (m.d.) leech" <mleech@bnr.ca>
From: cme@cybercash.com (Carl Ellison)
Subject: Re: Specification languages
Cc: spki@c2.org
Message-Id: <v02140b15ad5a89f6dee5@[]>

At 16:25 2/28/96, marcus (m.d.) leech wrote:

looks good, with one confusion for me:

>typedef Signature
>     KeyId          uint64
>     OtherIdent     octets
>     OthIdType      uint8
>     SigType        uint8  selects(SigBytes)
>       SigBytes[0]    RSASignature
>       SigBytes[1]    DSSSignature

isn't clear in how it's going to show up in C or PASCAL.
What were you envisioning?

typedef Signature
     KeyId          uint64
     OtherIdent     octets
     OthIdType      uint8
     SigType        uint8  selects
      {0: (rsa    RSASignature )
       1: (dss    DSSSignature )

is one that would translate directly to PASCAL, so I can
envision it immediately.

 - Carl
From ???@??? Wed Feb 28 13:44:03 1996
Return-Path: <owner-spki@c2.org>
Received: from callandor.cybercash.com (callandor1.cybercash.com) by cybercash.com (4.1/SMI-4.1)
        id AA01296; Wed, 28 Feb 96 13:05:15 EST
Received: by callandor.cybercash.com; id NAA07241; Wed, 28 Feb 1996 13:15:18 -0500
Received: from infinity.c2.org( by callandor.cybercash.com via smap (g3.0.3)
        id xma007233; Wed, 28 Feb 96 13:14:52 -0500
Received: (from daemon@localhost) by infinity.c2.org (8.7.4/8.6.9)
        id JAA05020 for spki-outgoing; Wed, 28 Feb 1996 09:54:22 -0800 (PST)
        Community ConneXion: Privacy & Community: <URL:http://www.c2.org>
From: baos@oss.oss.com (Bancroft Scott)
X-Mailer: SCO System V Mail (version 3.2)
To: oss!baos@uunet.uu.net, perry@piermont.com
Subject: Re: going back to stone axes
Cc: cme@cybercash.com, mcr@milkyway.com, spki@c2.org
Date: Wed, 28 Feb 96 12:43:24 EST
Message-Id:  <9602281243.aa14166@oss.oss.com>
Sender: owner-spki@c2.org
Precedence: bulk


> > Anway, the notation is the way it is so that you can specify semantics 
> > other than just the number of bits required to hold the integer value.  For
> > example, an integer type may be defined as "INTEGER (0 | 20..100 | 200)"
> > which says that the integer value can be 0, 20-100 or 200.  This
> > expresses more about the type than simply saying that it is an
> > unsigned integer value that fits into two bytes.
> [Personal opinion]
> Certainly thats cute, but is that actually desirable?

It is actually very useful.

> > Of course you can always state such restrictions in comments, but by
> > embedding this information in the definition of the type you add no
> > complexity to the implementor's program if they wish to manually check
> > the constraints on the integer
> Sorry, but no. That is simply untrue. I have written, as I noted, a
> [...]

Nonsense!  Explain how adding subtype constraints makes a DER or BER
implementor's program more complex.  Remember that subtype constraints
have zero effects on the bits on the wire in BER and DER.

> You can go on claiming that real world experiences like this don't
> actually exist, but they do. Many of us are not claiming that ASN.1 is
> undesirable because we are unwashed fools who have no experience with
> it. We are claiming it precisely because we once thought it was a neat
> idea and then got our heads handed to us by the Gods of Programming
> for our hubris. Ask Ted T'so or Jeff Schiller if they would have put
> ASN.1 inside the Kerberos V protocol if they had it do do all over
> again.

Ted T'so and Jeff Schiller stubbing their toes using ASN.1 simply
points out that, like any other language, ASN.1 can be used poorly;
nothing more.  There are more than a couple folks who have designed C,
C++, Pascal, ..., programs poorly, does this mean that these languages
are inherently?  No.  The same is true for ASN.1.

You can go on claiming that real world experiences of successful use
of ASN.1 outside the OSI world don't greatly outweigh the couple
failures that you keep bringing up, but they do.  You might want to
contact the implementors of T.120, TDP, etc., to see what they think
of using ASN.1.  These (non-OSI) standards rely very heavily on ASN.1
and I am certain their implementors will tell you that they are better
off for having done so.

> [Opinion as Chair]
> In any case, I want to make something very clear before we continue
> down this rathole much further. This group does *not* exist to simply
> be another rubber stamp for the X.509 protocol, and there certainly
> does not seem to be consensus thus far for any sort of specification
> language for our formats, let alone ASN.1. Given this, I'd say that
> there is a limit to how much use rehashing old debates about ASN.1.

It makes sense that both sides of the arguments be aired.  You may
wish to relate the bad experiences that some have had implementing a
couple protocols that use ASN.1, fine.  But don't try to stifle
arguments that relate the positive experiences that so many have had
in implementing protocols that use ASN.1.  The fact is that the number
of well designed protocols out there that use ASN.1 and whose
implementations have been greatly simplified by its use far outweigh
the couple botched designs that you keep harping on.

Also, if you are going to invoke the voice of the chair you might want
to be less partial.  Take a look at the mail over the last few days
and you will observe that the only times that you or Carl Ellison
speak up for moving the discussion away from X.509 or ASN.1 are when
their positive aspects are being brought to light.  Not nice!

Bancroft Scott