-----Original Message-----
From: cloud-directory@googlegroups.com [mailto:cloud-directory@googlegroups.com] On Behalf Of Kelly Grizzle
Sent: Wednesday, April 11, 2012 6:12 AM
To: cloud-directory@googlegroups.com
Subject: RE: group namespaces

Leif,

Have you seen the targeting proposal yet?  I'm not sure if this would address your need, but multi-tenancy is was considered with targeting.

https://datatracker.ietf.org/doc/draft-hunt-scim-targeting/

--Kelly

-----Original Message-----
From: cloud-directory@googlegroups.com [mailto:cloud-directory@googlegroups.com] On Behalf Of Leif Johansson
Sent: Wednesday, April 11, 2012 3:15 AM
To: Cloud Directory
Subject: Re: group namespaces

On Apr 11, 10:00 am, Samuel Erdtman <sam...@erdtman.se> wrote:
> Not completely sure, but I think that Morteza means

> POST /another/namespace/Groups

> I.e. Namespace/Tenant comes before (in url) what is defined by the
> SCIM 1.0 specification. This is defined as Base URL in
> sectionhttp://www.simplecloud.info/specs/draft-scim-api-00.html#defs

> //Samuel

OK I guess that makes sense. This seems like something that needs to be clarified in the spec :-)

> On Wed, Apr 11, 2012 at 9:50 AM, Leif Johansson <le...@mnt.se> wrote:

> > On Apr 10, 11:59 pm, "Morteza Ansari (moransar)"
> > <moran...@cisco.com>
> > wrote:
> >> Hi Leif,

> >> Welcome to the group!  I was hoping to catch up with you in Paris,
> >> but the week went by so quickly.

> > Quite

> >> In general the namespace is not defined as part of the SCIM spec
> >> itself as there were two scenarios that were discussed. The first
> >> case is when the namespace is global (giant single tenant) where a
> >> username is a username and it must be unique globally. The other
> >> case was when namespace is segmented and for that case
> >> (multi-tenant), the URL is the qualifier to the namespace to make it globally unique.

> > Ah so in that case you'd (say) POST to /Groups/a/nother/namespace/
> > to create a group for instance? If so the spec isn't exactly clear
> > on that option...

> >> I have not heard of anyone requesting extension for solving the
> >> namespace. Though your use case might be a new one driving such
> >> requirement.  I would be interested to hear if the URL
> >> qualification solves your use case.

> > Using the URI would be preferred!

> >> How extensions are managed is pretty vague and is one of the
> >> reasons we wanted to move this work to IETF to define better process around it.

> > OK good then. We should talk about that some more. There are other
> > groups talking about a post-rfc2252 attribute language.

> >> And I will skip answering your last question ;-)

> > Excellent!

> >> Cheers,
> >> Morteza

> >> -----Original Message-----
> >> From: cloud-directory@googlegroups.com

> >> [mailto:cloud-directory@googlegroups.com] On Behalf Of Leif
> >> Johansson
> >> Sent: Tuesday, April 10, 2012 2:41 PM
> >> To: Cloud Directory
> >> Subject: group namespaces

> >> I'm fairly new to this group (although not to some of the work that
> >> is tangential to SCIM - some of you know me from IETF and other
> >> places) so forgive me if this has been raised before....

> >> I have an application where groups have names that are part of
> >> managed name spaces - mostly used for managing access control. As I
> >> started to implement a SCIM server for this application it dawned
> >> on me (call me stupid for not realizing this) that SCIM doesn't
> >> have any concept of name space for any of its standard resources. I
> >> realize that it would be fairly easy to define an extension schema
> >> for groups that define 'name_space' attribute but since all clients
> >> would have to implement this extension in order to create groups
> >> (since name_spaces are the basis for ACLs) in my implementation,
> >> chances for interoperability would be somewhat limited.

> >> Here are some questions...

> >> - has name spaces for groups or any other type of resource been
> >> discussed?
> >> - is anyone else considering similar extensions?
> >> - how is an extension schema documented - i.e what does rfc2252
> >> look like for SCIM?
> >> - should I just give up and roll my own API?

> >>      Cheers Leif