RE: [provision] SPML 2.0 Relationships proposal...

["Jeff Bohren" <jbohren@opennetwork.com>]

Comments inline.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 
Try the industry's only 100% .NET-enabled identity management software.
Download your free copy of Universal IdP Standard Edition today. Go to
www.opennetwork.com/eval.
 
 

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Tuesday, August 03, 2004 3:50 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] SPML 2.0 Relationships proposal...

Jeff Bohren wrote:

> Attached is the first draft of my proposal for handling relationships.

> This covers both containment and references. It supports references 
> with attributes. It also supports relationships (both kinds) as search

> criteria and also as search results. I believe that this proposal 
> meets all of the requirements discussed so far.
>
Thanks, Jeff.

1) I was under the impression that each target would declare the 
capabilities that it supports, but you seem to be saying that the 
containment capability will be declared at the level of an individual 
PSO type.  This is more granular than I had understood the target's 
capability map to be.

[JSB] Capabilities can be defined on a per-target basis or on a per PSO
type basis. In reality defining capabilities on a per-target basis only
makes sense if the target only defines on PSO type. The important
information is what capabilities a PSO supports regardless of how it is
defined. For instance it is important to know that an org unit PSO type
does not support password resets and that a Solaris account PSO types
does not support state (yes, I know some vendors do this via passwords).


2) The second sentence in the Containment section could be 
misinterpreted to mean that you propose to change the core 'add' 
operation.  Perhaps it could be reworded along the lines of :
   The optional containment interface will define an 'add' request
   that extends the core 'add' request.....

[JSB] I'm not going to word smith this document much. It's just a
proposal. The real word smithing will be done to the actual spec, after
we decide on the technical details.

3) It may be worth mentioning (for the benefit of reviewers) that 
containment is a simple relationship.  You brought this up in today's 
discussion, and I thought this was an excellent point of clarification.

[JSB] See previous comment on word smithing.

4) I would be happier if gave these operations different names (rather 
than simply overloading a signature or--in this case--extending a core 
operation under the same name in a different namespace).  I'd rather 
call this operation "addChild" or "addToContainer".  I suggest renaming 
"spmlcontain:AddRequestType" to "spmlcontain:AddChildRequestType".  The 
AddChildRequestType could still extend spml:AddRequestType.  I just want

to give the operation a different and more descriptive name.

[JSB] In my view that would be more confusing. If I was writing an API,
to me it would be very clear to write:

add (id, data)
add (container, id, data)
add (container, id, data, references)

Your suggestion would be something like:

add (id, data)
addChild (container, id, data)
addChildWithReferences (container, id, data, references)

5) Along the same lines as the previous comment, I'd suggest that we 
rename the 'move' operation to 'setParent' or 'setContainer'.  (I know 
that 'move' means 're-parent' in LDAP-land, but I'd prefer to make this 
more explicit.)  Of course, "spmlcontain:SetParentRequestType" could 
still extend "spml:BatchableRequestType".

[JSB] I'm not concerned too much about what we call this, however
"re-parent" would be inappropriate as it could be called on a PSO that
does not already have an explicitly defined parent.

6) I liked your comment about unidirectional relationships, and I 
suggest adding (for the benefit of reviewers) a sentence like:
    NOTE: Specifying reference relationships as unidirectional does not 
preclude a provider
    representing relationships as bidirectional; rather, this becomes a 
feature
    or an artifact of that provider's implementation.

[JSB] See previous comment on word smithing.

7) Same comment as (1), this time for reference relationships.  
Declaring support for a reference capability at the level of an 
individual PSO type is more granular than I had previously understood a 
target's capability map to be.  (I thought each *target* declares the 
optional interfaces it supports.)

Not only do we need to specify what PSOs support the reference
capability, we also need to specify what are the allowed references that
can be created. For instance it is important to know that a user PSO
type might support the "memberof" reference, where as an org PSO type
would not.

8)  The terminology of "Reference ID", "Referent ID" and "Reference 
Attributes ID", while technically accurate, can be confusing.  I suggest

using terms like "From ID" and "To ID" and "Connection ID" (if not as 
the actual terms then at least to explain them).
    From ID - identifies the reference--the source or "from" object.
    To ID - identifies the referent--the target or "to" object.
    Connection ID - (optional) identifies an object that represents
                          any "extra" information about this
relationship.

[JSB] I could go either way on this.

9)  I think you forgot a field: "Connection Type".   You could call this

"Relationship Type", but it's the same idea.  Several connections, each 
of a different type, may connect any two objects.  Each connection type 
in essence defines a separate namespace.  (Without this, a request to 
delete or modify a connection might remove or update the wrong
connection.)

[JSB] The Reference ID is the "Connection Type". For instance if a user
is a member of two groups and owns a PDA, there references might be:

1: refID=memberOf, referentID=group1
2: refID=memberOf, referentID=group2
3: refID=owns, refentID=PDA12

10)  I really wish there were some way to avoid making the (optional) 
relationship object a PSO (and giving it an ID).  As we discussed at 
Long Island, persistently storing these objects (and mapping each to the

appropriate target object or API) creates scale problems for a 
provider.  Experience suggests that the number of connections may be an 
order of magnitude or more greater than the number of objects connected.

Rather than identifying a complex connection by an ID, could we specify 
a complex connection instance by its From ID, To ID, and Connection 
Type?  If a provider can map these identifiers to the appropriate target

object or API, then we avoid persistently storing each complex 
connection object as a PSO (and continually having to map its ID).

In the case of the RACF, these arguments map cleanly to the API.  In the

case of a directory object, it might be necessary to find the connection

object by starting at one end (either source or target) or by searching 
for an object that connects both the "fromID" and the "toID".

As a consequence, one would modify connection attributes by passing any 
object representing a complex connection as part of the 'connect' 
request.  A single 'connect' verb could implicitly modify any existing 
connection between the specified "from" and "to" objects (as it does in 
RACF), or we could define separate  verbs to "addConnection" and 
"modifyConnection".

Do you see any problems with this kind of approach?  Is it possible to 
avoid representing each complex connection object as a PSO?

[JSB] It is possible if the following restrictions are made:
1) There can not be two references with the same "from" and "two" IDs
but with different attributes.
2) The attributes are always updated as a set. In other words one RA can
not try to set the "admin" attribute on the same relationship while
another is trying to set the "audited" attribute on the same
relationships.
I think trying to avoid making the attributes a PSO is going to cause
more effort on the implementers than it is going to save.

11) Same as (9): need "Connection Type" in order to uniquely specify an 
connection (instance). 

[JSB] I don't understand this one.

12) As mentioned in (10), prefer to have explicit 'connect' and 
'disconnect' verbs.  However, I suppose that a single "modifyConnection"

could be used to add, modify, and delete connections.

[JSB] Again, I think:

modify (id, data)
modify (id, data, references)

is more clear than:

modify (id, data)
modifyConnection (id, references)

13) It's clear from the definition, but we should mention (for the 
benefit of reviewers) that SearchRequestType is defined in the "spmlref"

namespace and that this extends but does not change the core interface? 

14)  Same as (13), except for Search Response.

15)  We would not want including connections to "bloat" the size of 
every PSO returned by spmlref:search.  You mentioned some options to 
control whether connections (or perhaps which connections types) would 
be returned?

[JSB] Yes, ideally specifying which reference IDs would be returned
would satisfy this.

Gary