Re: GSS-API V2: C# Bindings
"Juan Carlos Luciani" <jluciani@novell.com> Tue, 31 January 2006 16:26 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yLF-0003DV-Ta; Tue, 31 Jan 2006 11:26:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yL9-0003Bo-Cm for kitten@megatron.ietf.org; Tue, 31 Jan 2006 11:26:52 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03397 for <kitten@ietf.org>; Tue, 31 Jan 2006 11:25:02 -0500 (EST)
Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3yVy-0001io-V0 for kitten@ietf.org; Tue, 31 Jan 2006 11:37:59 -0500
Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Tue, 31 Jan 2006 09:26:22 -0700
Message-Id: <43DF2D2E.365D.009A.0@novell.com>
X-Mailer: Novell GroupWise Internet Agent 7.0
Date: Tue, 31 Jan 2006 09:26:06 -0700
From: Juan Carlos Luciani <jluciani@novell.com>
To: Horst Reiterer <horst.reiterer@mind-breeze.com>
References: <43DD65A8.10200@mind-breeze.com>
In-Reply-To: <43DD65A8.10200@mind-breeze.com>
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8
Cc: kitten@ietf.org
Subject: Re: GSS-API V2: C# Bindings
X-BeenThere: kitten@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kitten>
List-Post: <mailto:kitten@lists.ietf.org>
List-Help: <mailto:kitten-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1964150486=="
Sender: kitten-bounces@lists.ietf.org
Errors-To: kitten-bounces@lists.ietf.org
Hi Horst, After reading the .NET naming guidelines, I agree with your assessment that the bindings should use Pascal casing for methods, properties as well as constant value names. I also agree that classes that need to provide explicit control to developers for when native resources are released should implement the IDisposable interface to be compatible with the .NET Framework's Dispose pattern. I will update the draft with the naming changes and with the changes to the GSSCredential and GSSContext classes indicating that they implement the IDisposable interface. Please let me know of any other issues that you may see. Thanks you very much for your help, Juan Carlos Luciani >>> Horst Reiterer <horst.reiterer@mind-breeze.com> 01/29/06 6:02 pm >>> Juan Carlos, I am working on integrating Kerberos authentication into a Mono-based application (possibly the Mono Framework implementation itself if I can find the time) so that native Kerberos clients can interoperate with Mono-based services. While starting the implementation, I've come across your GSS-API C# bindings draft: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-csharp-bindings-00.txt I'm glad that bindings already exist or are being worked on at the moment. In the introduction, you mentioned that one of the design goals was to emulate the Java bindings specified in RFC 2853 as much as possible while still taking advantage of C# features such as Properties. I fully agree here! I must say however that the bindings IMHO follow the original too closely in some respects. Let me mention two concrete examples: a) byte[] acceptSecContext(byte[] inTok, int offset, int len); Methods, properties as well as constant values (e.g. NO_CONTEXT) violate the .NET Framework coding guidelines as defined by Microsoft (methods properties and constant values should use Pascal casing). For a C# developer, it is very inconvenient to work with a library that does not follow the platform's naming conventions for example. Modifying the bindings to follow the guidelines would IMHO make it's interface significantly more intuitive. Was there a particular reason why you've chosen to follow the Java naming conventions here? References: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp b) void dispose(); In my opinion, this is a very serious issue because this disposal facility simply bypasses the .NET Framework's Dispose pattern and thus does not allow developers to handle objects with native resources accordingly. As a .NET Framework developer, I would expect the following (modified sample taken from the draft) to work: // ... GSSCredential cred = mgr.createCredential(name, GSSCredentialUsage.ACCEPT_ONLY); using (cred) { Oid[] mechs = cred.getMechs(); if (mechs != null) { for (int i = 0; i < mechs.length; i++) Console.WriteLine(mechs[i].ToString()); } } Unfortunately, it can't because the class does not implement IDisposable (unless I missed something). My strong recommendation would be to follow the Dispose pattern in all cases involving native resources so that language / platform facilities (as demonstrated above) can be taken advantage of. References: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/cpgenref/html/cpconfinalizedispose.asp Does a reference implementation of the draft (or at least class and interface definitions in source code form) already exist? Please let me know so that I can decide how to proceed in respect to integrating Kerberos. If it doesn't, I would be forced to roll out my own implementation. I'd be more than happy to provide you with further input for the sake of maximizing the value for developers interacting with the GSS-API using C#. Thanks for your time, I highly appreciate your work! Cheers, Horst.
_______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten
- Re: GSS-API V2: C# Bindings Juan Carlos Luciani