Re: GSS-APIv3 sketch

"Stefan (metze) Metzmacher" <> Thu, 12 November 2009 12:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 666343A681D for <>; Thu, 12 Nov 2009 04:03:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NkdI49wrp83f for <>; Thu, 12 Nov 2009 04:03:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6133E3A6818 for <>; Thu, 12 Nov 2009 04:03:36 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (SASL METHOD:[PLAIN] USERNAME:[metze]) by (SMTP-MAIL-SERVER) with ESMTP id 1C9B720C554; Thu, 12 Nov 2009 13:04:01 +0100 (CET)
Message-ID: <>
Date: Thu, 12 Nov 2009 13:03:49 +0100
From: "Stefan (metze) Metzmacher" <>
User-Agent: Thunderbird (X11/20090817)
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@Sun.COM>
Subject: Re: GSS-APIv3 sketch
References: <20091111181140.GC10501@Sun.COM> <> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM> <> <20091111230044.GW1105@Sun.COM> <20091111232007.GI10501@Sun.COM>
In-Reply-To: <20091111232007.GI10501@Sun.COM>
X-Enigmail-Version: 0.95.7
OpenPGP: id=0E53083F
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigA682073F2BB7555BEF76C324"
Cc: "" <>, vl <>, Love Hörnqui st Åstrand <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Nov 2009 12:03:38 -0000

Nicolas Williams schrieb:
> On Wed, Nov 11, 2009 at 05:00:45PM -0600, Nicolas Williams wrote:
>> I think implementations could certainly have such interfaces, but I
>> think we'd not standardize them here.
> On second thought, I think we could do non-threaded async APIs as
> separate RFCs, one for each event interface.  We might end up with only
> one: libevent.
> One sketch:
>  - app calls set_async_XYZ() on a call context handle to register
>    XYZ-specific event loops
>  - init/accept_sec_context() return S_ASYNC_CONTINUE_NEEDED
>  - app calls init/accept_sec_context() again when a related event is
>    posted
> Another:
>  - app calls set_async_XYZ() on a call context handle to indicate the
>    desire to do XYZ-specific async calls
>  - init/accept_sec_context() return S_ASYNC_CONTINUE_NEEDED
>  - app calls get_async_XYZ() on the call context handle to get
>    XYZ-specific event descriptions that the app then handles in an
>    XYZ-specific way
>  - app calls init/accept_sec_context() again when a related event is
>    posted

I think such models could nicely work from the callers view.
But init/accept_sec_context() should only return A_ASYNC_CONTINUE_NEEDED
once! And the caller gets only notified when the function has completed,
so that the caller can get the result.

The main remaining problem has to do with the mech implementations, they
need an api to register different types of events.

Think about this:

A system has a with mechglue code and a few
mech implementations by different vendors.

Then some application wants to use libevent with the

On the same box samba wants to use it's tevent library

And a third application wants to use the glib event code

The mech implementations should work in all 3 cases
without knowledge about the specific event system.