[17430] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: Future ASN.1 support

daemon@ATHENA.MIT.EDU (Nathaniel McCallum)
Fri Dec 9 10:15:54 2011

Message-ID: <1323443745.12079.119.camel@localhost>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: ghudson@mit.edu
Date: Fri, 09 Dec 2011 10:15:45 -0500
In-Reply-To: <201112081744.pB8Hi9DU005220@outgoing.mit.edu>
Mime-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

On Thu, 2011-12-08 at 12:44 -0500, ghudson@MIT.EDU wrote:
> 3. New ASN.1 compiler + modified existing code: in this plan we alter
> our ASN.1 infrastructure to (1) be less tailored to RFC 4120 idioms,
> (2) support data-driven decoding as well as encoding, and (3) throw
> out the CPP macros for generating data structures.  Then we write a
> new ASN.1 compiler in Python which generates the data structures based
> on an ASN.1 module and some additional input describing our data
> structures.
>  ...
> Currently I'm exploring the third option, but I'm interested in
> opinions on which option is best or whether I should be looking at
> other options.

While I fully admit I'm not ASN.1 guru (neophyte is a better
description), I have to think that writing your own ASN.1 compiler has
to be at least as much work, if not more, over the long term as
migrating data types or some of the other possibilities. I mean, I've
asked 3 people experienced with ASN.1 what tool I should use and got 4
different answers. I'd hate to add a 5th to that list. I don't want to
be critical, and I know I'm the new guy, but this seems like NIH.

_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post