Re: [provision] Spec issues #22 and #23: AddRequest targetID,con tainerID and psoID.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

We've now pinpointed my confusion.  In XSD 16,  Jeff added containerID 
to PSOIdentifierType.  (I may have overlooked some of the implications 
in my concern over whether targetID is an attribute.  These issues are 
slightly tangled.  I hope we can pin that down soon.)

HOWEVER...the fact that "containerID" is *optional* in PSOIdentifierType 
makes it a little confusing to say (as Jeff says of case #3), that
    "The targetID and containerID should not be specified because they 
are part of the psoID."

The containerID is *not necessarily* part of the psoID, but I guess you 
could say that if the psoID
lacks containerID then this means that the object should be bound at 
top-level (directly beneath the target).

This seems just a little too tricky to me--imputing meanings from things 
being missing (rather than being specified).  I tend to think that this 
is clearer with targetID as an attribute, but that's a separate issue.  
Maybe resolving that issue will also resolve this one.

Bohren, Jeffrey wrote:

>1) The targetID is specified and the containerID and psoID are not
>specified. In this case no containment is specified and the SPML service
>will calculate and return the new psoID. If the target supports containment,
>the new PSO will be a root PSO of the target and the psoID will not have a
>defined container.
>  
>
I don't think a PSOIdentifierType has a containerID.

> 
>2) The containerID is specified and the targetID and the psoID are not
>specified. In this case the SPML service will calculate and return the new
>psoID, where the new psoID has the specified containerID as it's container.
>The targetID should not be specified because it is part of the containerID.
> 
>3)  The psoID is specified and the the targetID and the containerID are not
>specified. In this case the SPML service is allowing the SPML client to
>define the psoID. This is most likely the case in a federated provisioning
>scenario where a IdP provisions identities to an SP prior to federated SSO.
>The targetID and containerID should not be specified because they are part
>of the psoID.
> 
>In all three of these cases, the targetID may be ommitted completely if
>there is only one target.
> 
>Jeff Bohren
>BMC
> 
>
>-----Original Message----- 
>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
>Sent: Thu 5/12/2005 4:14 PM 
>To: PSTC 
>Cc: 
>Subject: [provision] Spec issues #22 and #23: AddRequest targetID,
>containerID and psoID.
>
>
>
>Agreed during the 20050510 conference call to discuss these issues on 
>the list. 
>Forwarding "AddRequest targetID, containerID and psoID" originally 
>posted to the list 4/21/05. 
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>  
>