Re: [provision] Groups - 2.0-Relationships.pdf uploaded

[Shmuel Koller <shmuelk@yahoo.com>]

Gary and Doron, to better explain:

PML can FULLY  provision Connections as follows:

<xsd:extension base="spml:SpmlRequest">
<xsd:sequence>
<xsd:element name="identifier" type="spml:Identifier"
minOccurs="0" maxOccurs="1"/>
<xsd:element name="identifier2" type="spml:Identifier"
minOccurs="0" maxOccurs="1"/>
<xsd:element name="attributes" type="spml:Attributes"
/>

I added a line for identifier2 in my copy of spml 1.0
xsd. It is an optional identifier, so the request may
have a Pair of identifiers.

That means any SpmlRequest can have 2 Identifiers.
And everything else remains the same, we keep the
basic   set of SPML commands.

When the RA-PSP exchange occurs for a pair of
identifiers like (user1, group1) - objectclass can be
Connection and an attribute/value  in the Attributes
sequence can be connectionType=RACFGroupMembership.
Thus we cover every functionality needed to provision
Connections.

That means we do not need connect and 
modify-connection commands:
Connect is done via spmlAdd (id1,id2)
Modify connection is likewise spmlUpd(id1, id2)
Similarly Disconnect will be done by spmlDel(id1,id2)

SchemaExchange I think is typed in spml 1.0  by the
objectClass. The objectClass determines the set of 
Attributes (the schema).

To cover Connection, the Schema Exchange must also
have objectClass=Connection, and an attribute
ConnectionType=RACFGroupMembership, if it is desired
to have this granularity of SchemaExchange.

The main point is Identifiers pair as an option of
every SPML request. And solve all issues while keeping
simplicity - to have full coverage of "provisioning a
connection". That is - give SPML implementations the
power to provision Connections while containing this
power in the SPML commands (with two identifiers) -
and not in any complex data model.

My point Gary is not to limit (id1, id2) to 
objectClass=Connection. In other words - avoid a fixed
affinity between the presence of Two identifiers and
some fixed concept (connection) in the Data Model. Its
just two identifiers in the SPML verb/command, that
will allow full semantics of provisioning Connections
- by minimal change in the Verbs (spml commands) -
change  to support from now TWO identifiers.

I hope I clarified  the basic idea of identifiers
pair.
Sorry - I am not up to date of spml 2.0, and hope that
referring to spml 1.0 - just to explain this
particular idea - is OK.

Shmuel Koller
Bank Leumi

		

--- Gary P Cole <Gary.P.Cole@Sun.COM> wrote:
> Shmuel,
> 
> Thank you very much for your suggestions.  I
> appreciate you contributing 
> new ideas to this discussion.  My questions and
> comments are inline below.
> 
> Shmuel Koller wrote:
> 
> >Minor requirement point - I think for completness
> of
> >this particular discussion  - SPML search needs
> also
> >to support Retrieval of "connection attributes" in
> >addition connect and modify-connection. So we need
> >schema attributes for connection once again as per
> >Gary concern Third step below.
> >  
> >
> 1) I suggested that we do not necessarily need a
> verb to 
> 'modify-connection' if the 'connect' verb is
> understood to modify any 
> existing connection between the specified objects. 
> What is your opinion?
> 
> 2) I suggested that we _would_ need some kind of
> schema for a complex 
> connectionType (and I asked Doron whether he agreed
> with that 
> assessment).  If am secretly hoping that there is
> some way to avoid 
> having to expose schema for complex connection
> types, since this adds 
> overhead to the implementation, but I do not see how
> we could do that. 
> 
> To be perfectly plain about my bias, I do not want
> to add support for 
> complex relationship types if this complicates
> support for simple 
> relationship types.
>  
> 
> >The solution is I think between Long Island and
> >current discussion. Support Primary Identifier and
> >Secondary identifier (order is important, to the 
> PSP
> >implementation).
> >
> >This will keep SPML simple - as all provisioning
> basic
> >commands will apply to connections, via
> specification
> >of a Pair of Identifiers, also Schema exchange.
> >
> How would schema exchange apply to identifier pairs?
>  Are you suggesting 
> that a pair of types is also a type, so that
> {Type1,Type2} could have 
> its own schema?
> 
> > 
> >
> >That done - it does not limit the semantics of the
> >Identifier Pair to mean "connection" but anything
> that
> >the PSP wishes, and again - the identifier orders
> >order can matter or not to the implementation.
> >  
> >
> This is an interesting possibility, but I'm not sure
> that I find that 
> degree of freedom to be attractive.  One of our
> goals for SPML 2.0 is to 
> make the protocol better reflect the domain of
> provisioning.  I think I 
> like the idea of an identifier pair better if an
> identifier pair 
> *always* refers to a connection.
> 
> >With SPML 1.0 and its verb "simplicity yet powerful
> >for provisioning" - that was a choice - to
> implement
> >the Connection pair of identifier as "string
> >concatenation"  
> >into one SPML identifier. I think its worth to let
> >SPML express an Identifiers Tupple (or at least
> pair)
> >and keep its command set simple - while enriching
> the
> >data model (to FULLY express provisioning of
> >connections, but not represent them).
> >
> >I think the pair of identifiers can be considered
> as
> >much stateless and non-persistent as one identifier
> -
> >for this matter. Its just a "key" for the SPML
> >provisioning command. And - at the same time it
> >provides full coverage for provisioning
> connections,
> >where (if and only if  implementation wishes so): 
> >spmladd(id1,id2) - means connect 
> >spmldel(id1,id2) - means disconnect 
> >spmlget(id1,null) - as if just id1
> >spmlget(id1) - will cascade to delete connection
> >(depends on implementation)
> >  
> >
> I think you meant "spmldel(id1) - will cascade to
> delete connection", right?
> 
> Again, I think that this idea is interesting and
> powerful, but I'm 
> concerned that it may be overly abstract.  I think
> that I prefer to have 
> explicit 'connect' and 'disconnect' operations.
> 
> We've done a fair amount of work (after a great deal
> of discussion) to 
> separate the verbs proposed for SPML 2.0 into
> separate core and optional 
> interfaces.  This allows each provider (and indeed
> each target) to 
> declare which operations it supports.  This
> suggestion would take us 
> back in the other direction, making it more
> difficult to determine which 
> "flavors" of an operation a provider supports.
> 
> >The SPML opportunity here to stay simple and
> powerfull
> >is that ConnctionType is an Attribute of (id1,id2) 
>   
> >  
> >
> I would like to better understand this suggestion. 
> I can imagine that a 
> connectionType might be represented as an attribute
> of (Type1,Type2) in 
> the schema, but  I  do not see how a connection
> *type* could be an 
> attribute of two *instances*.  That's probably not
> what you meant.  What 
> did you mean?
> 
> Thanks,
> 
> Gary
> 
> 
> To unsubscribe from this mailing list (and be
> removed from the roster of the OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php.
> 
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail