Comments inline below…
Jeff Bohren
BMC
-----Original Message-----
From: Sodhi, Gavenraj S
[mailto:]
Sent: Friday, June
24, 2005 7:01 PM
To:
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
