Subject: Re: comments draft-ietf-kitten-gssapi-naming-exts-05.txt

From: Leif Johansson <[email-masked]>
Date: Tue, 17 Nov 2009 15:19:30 +0100

> gss_buffer_set_t it is then unless people scream bloody murder at it
> fairly soon

So Luke pointed out that we need to pull in gss_buffer_set_t from
somewhere and the only reference he could think of was the GSI
draft which isn't a standards-track RFC.

Of course I can copy the gss-buffer stuff but maybe it should be
a separate document... possibly for inclusion into v3 later on?

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Tue, 17 Nov 2009 15:21:39 +0100

> I've never been comfortable with this API - it feels difficult to specify 
> property. I'd be in favor of dropping it.

I'd like to confirm that we have consensus on dropping gss_name_to_any
(or consensus that I misunderstood that thread)

	Cheers Leif

---

From: Luke Howard <[email-masked]>
Date: Tue, 17 Nov 2009 16:47:09 +0100

On 17/11/2009, at 3:21 PM, Leif Johansson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

I don't mind, however we did implement it.

-- Luke

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Nov 2009 10:46:32 -0600

> (or consensus that I misunderstood that thread)

I'm for dropping it, but Luke seems to think it's useful, and he did
implement it, including a plug-in interface.  Luke?

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Tue, 17 Nov 2009 18:17:09 +0100

> implement it, including a plug-in interface.  Luke?

I only really implemented it because it's in the spec. But there are  
cases where it may be useful -- but those all defeat the purpose of a  
general-purpose, mechanism-agnostic API. For example, the SAML  
provider surfaces the assertion object via this interface, but then it  
requires the caller be using the same SAML implementation.

-- Luke

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 17 Nov 2009 14:04:04 -0800

> requires the caller be using the same SAML implementation.

I think that when we get a real use for it we can add it all back.

Pushing out random objects is sane.

Love

---

From: Luke Howard <[email-masked]>
Date: Wed, 18 Nov 2009 00:52:22 +0100

> Pushing out random objects is sane.

Or insane? :-)

-- Luke

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 17 Nov 2009 15:58:44 -0800

>> Pushing out random objects is sane.

yes sorry.

Love

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Nov 2009 17:57:25 -0600

> Pushing out random objects is sane.

Insane, yes.  My original use had been for an OS-specific view of things
like the PAC.  But as long as there's few consumers or the parsing code
can live in a library, then there's no need for this.  I.e., there's no
need for this -- it was a mistake on my part to include it in the first
place.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 18 Nov 2009 13:45:36 +0100

> need for this -- it was a mistake on my part to include it in the first

OK I'll venture to declare consensus on that point then. That just
leaves one item for me before I can get out 06: where to define
gss_buffer_set_t and related functions: separate document or inline?

	Cheers Leif