To: baos@oss.oss.com (Bancroft Scott) From: cme@cybercash.com (Carl Ellison) Subject: RE: going back to stone axes Cc: FreedmanJ@mail.ndhm.gtegsc.com, spki@c2.org Bcc: X-Attachments: Message-Id: 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. >If >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 use SEQUENCE OF, SET OF, CHOICE, .... 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" From: cme@cybercash.com (Carl Ellison) Subject: Re: Specification languages Cc: spki@c2.org Bcc: X-Attachments: Message-Id: 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: 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(140.174.185.11) 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: 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 Perry, > > 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