Subject: naming extensions outstanding issues take 2

From: Leif Johansson <[email-masked]>
Date: Wed, 25 Mar 2009 19:28:03 +0100

So pending confirmation on the list for mapped and negative/complete the 
remaining issue seems to be what to do about OID/string. I believe it is
reasonable to break this issue down in several smaller ones.

1. Is a change warranted at all?

2. If we want "strings", how should they be represented, gss_buffer_t * or 
const char * ? I've hear arguments for both - Love I think said he preferred
buffers over const char* and Nico may have stated his preference for 
the latter.

3. if we want "strings", what constraints do we want to place on those 
strings: any null terminated string or a specific syntax? My suggestion 
is that we say the string SHOULD contain a URI but MAY contain any
string and add a note on how to achieve maximum interoperability. We
may want to add a list of mandatory-to-implement attributes associated
with each underlying technology. My reason for URIs is that 
each OID is a URN (urn:oid:...) is a URI so by referencing URIs we 
will be covering (imo) all the significant use-cases.

4. Do we need a registry? That will depend on the outcome of 3.

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Mar 2009 13:58:44 -0500

> buffers over const char* and Nico may have stated his preference for 

I prefer buffers too because these will be returned by the mechanism and
may not be constants: the name may not be known to the mechanism, but
derived from a typed-hole in the mechanism's PDUs, like krb5 authz-data.
But the buffer contents should be strings -- US-ASCII or UTF-8 strings
to be specific.

> will be covering (imo) all the significant use-cases.

I'm fine with URIs.

> 4. Do we need a registry? That will depend on the outcome of 3.

Probably not, or, at least it should not be a requirement that any
naming extensions used through this API be registered.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 26 Mar 2009 00:19:15 +0100

On Wednesday 25 March 2009 19:58:44 Nicolas Williams wrote:
> > 2. If we want "strings", how should they be represented, gss_buffer_t *
> > or const char * ? I've hear arguments for both - Love I think said he
> > preferred buffers over const char* and Nico may have stated his
> > preference for the latter.
>

I agree!

> > will be covering (imo) all the significant use-cases.

Good.

> naming extensions used through this API be registered.

I agree. 

Dang :-)

	Cheers Leif

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 26 Mar 2009 08:37:17 -0700

> But the buffer contents should be strings -- US-ASCII or UTF-8 strings

Agree.  RFC2744 already defines how memory management works for buffers, 
and uses them in every case where the API needs to return a string -- there 
are currently no cases where a char * is used for this.

>> will be covering (imo) all the significant use-cases.

I would just say that they _are_ URI's, rather than playing the "it SHOULD 
be a URI but use whatever you want" game.  All that will do is lead to 
interop problems.  Simply requiring that they always be URI's provides good 
assurance that there won't be collisions, leaves several avenues open for 
naming private extensions (register a domain, get an OID arc, etc).  It 
also eliminates the need to create any sort of registry, since it builds on 
existing registries.

-- Jeff

---

From: Leif Johansson <[email-masked]>
Date: Fri, 27 Mar 2009 18:15:22 +0100

> also eliminates the need to create any sort of registry, since it builds on

I guess I agree too - urn:x-foo:bla is just as good an identifier as bla and 
it contains the information that it is experimental in nature. 

	Cheers Leif