OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [provision] CA will be participating in the SPML v2 Interoperability Event - A few question (Looking for Responses) are inline in the message

Comments inline below…


Jeff Bohren



-----Original Message-----
From: Sodhi, Gavenraj S [mailto:Gavenraj.Sodhi@ca.com]
Friday, June 24, 2005 7:01 PM
To: provision@lists.oasis-open.org
Subject: [provision] CA will be participating in the SPML v2 Interoperability Event - A few question (Looking for Responses) are inline in the message


CA will be participating in the SPML v2 Interoperability Event


** Posting on behalf of CA Development Team** - Look for some responses…


Hi all,


Our team recently began working on migrating some of the components in the Computer Associates eTrust IAM Suite from SPML V1 to supporting the V2 of the specification.  We would be very interested in participating in the upcoming Interop event by providing both an RA and PSP.


I have some questions from beginning to work with the V2 specification that do not seem especially clear at this stage. Is anyone able to shed some light on them?

1.      I gather that with the open content model, a requestor or a provider can specify additional operational attributes when issuing and responding to SPML requests via the “any” elements. Similarly, we can store any implementation specific metadata information about the DSML attributes, assuming that the provisioning schema is represented in the DSMLv2 Profile schema, in the “any” elements. But IMHO, the “permission” metadata, which can be set to either read-only, write-only, or read-write, is a common and useful metadata information that can be included as an optional attribute of an <dsmlprofile:attributeDefinitionReference> element. What do you think?


[JSB] The problem is that in some cases the “permission” is not part of the metadata but is part of policies with respect to the identity of the requestor. In other words an attribute may be read-only to a client with one set of permissions but be read-write to a client is a different set.


2.      Is there a way for a provider to declare that it only supports a selected number of operations in one of the standard capabilities?


[JSB] No. It is assumed such cases are handled by exception rather than declaration.


3.      Why does an AddRequest have a separated “targetID” and “containerID” field while these fields are capable of being set as part of the “psoID”?


[JSB] SPML 2.0 supports both flat and hierarchical data models. If a hierarchical data model is used, then a new PSO can be added to the root target or to an existing container. Since the container specifies the target it exists on, the add request can specify either the target or the container.



4.      The “modificationMode” attribute of an <spmlcore:modification> element at the moment doesn’t have a default value. Should the default it to “replace”-mode to make things clearer?


[JSB] There should be a default. Replace would seem to be the logical choice.


5.      Do you think that there should be a standard way for the requestor to request the provider to return the list of affected PSO’s when performing a bulkModify or a bulkDelete operation? The Add and Modify operations already support this.


[JSB] Such a mechanism already exists. Simply supply the same search query in a search request, specifying that only the PSO ID should be returned. That would return the list of PSO IDs that would be affected by the appropriate bulk operation. This of course assumes the service that supports the bulk capability also supports the search capability.


6.      How do I store the list of sub-requests in a BatchRequest?  I can’t see it in the new Schema.


[JSB] The sub-request for a batch operation are included via the open content model. See the SPML 2.0 Specification document for examples.


7.      The Updates Capability seems like a useful operation, and there is an XSD for it, but there is no mention about it in the draft 9 of the specifications, can someone please explain why?


[JSB] That is an oversight. Thank you for pointing it out. I will touch base with Gary about this.


By the way, we are using draft 24 of the XSD. Thanks for your help.


Van Bui

eTrust, Computer Associates

Melbourne, Australia



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]