Subject: extensions-iana registry

From: Shawn Emery <[email-masked]>
Date: Tue, 08 Jun 2010 17:18:17 -0600

Based on IANA feed-back; the WG needs to reach consensus on how the 
GSS-API extensions are to be registered.  Options proposed:

     1. single GSS-API name-space registry
     2. separate registry - symbolic and constant registries
     3. registry per programming language
     4. multiple registries
     ...

Time-out is in two weeks (ending 6/22/10).

</co-chair> My preference is option 1.

Shawn kitten co-chair.
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 Jun 2010 19:21:00 -0600

>     1. single GSS-API name-space registry

That's my vote.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Jun 2010 06:25:04 +0100

>     1. single GSS-API name-space registry

I prefer this choice.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 18 Jun 2010 12:04:10 -0700

8 jun 2010 kl. 16:18 skrev Shawn Emery:

> 
> Based on IANA feed-back; the WG needs to reach consensus on how the GSS-API extensions are to be registered.  Options proposed:
> 

How would each of these look like ? Esp the first one.

Love

---

From: Shawn Emery <[email-masked]>
Date: Tue, 22 Jun 2010 23:52:33 -0600

1. single GSS-API name-space registry
A type that does not have separate symbolic and constant registries.  In 
other words, not 2 or 3.

2. separate registry - symbolic and constant registries
A constant registry contains entries specific to constant name-values.
A symbolic registry contains entries for non-constants, e.g. function 
names, name types, etc.

3. registry per programming language
Registries partitioned by programming language, for example:
Registry a. contains entries for bindings in C.
Registry b. contains entries for binging in Java.
...
Entries in a. and b. do not have to be unique, but all entries in each 
of the language registries should be specified.

4. multiple registries
Multiple registries is really 2 or 3.

Perhaps we should put an example with different name-space types in the 
appendix for the single name-space registry?  Would this help clarify?

Shawn.
--

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 23 Jun 2010 10:00:55 -0700

>> How would each of these look like ? Esp the first one.

I think I was more looking for examples.

For example, every time a new language is added, yet another row need to be added, and I'm concered how easy that is to manged and express to IANA what change we want to make.

I think there should be one registry for each language added and how it maps to the base specification language.

Love

> A type that does not have separate symbolic and constant registries.  In other words, not 2 or 3.
> 
> A symbolic registry contains entries for non-constants, e.g. function names, name types, etc.
> 
> Entries in a. and b. do not have to be unique, but all entries in each of the language registries should be specified.
> 
> 4. multiple registries
> Perhaps we should put an example with different name-space types in the appendix for the single name-space registry?  Would this help clarify?
> 
> Shawn.
> --