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] | [Elist Home]

Subject: RE: [provision] Reuse in SPML

It sounds to me like you didn't read my response thoroughly and are
assuming that I haven't read the SPML schema documents.  Let me rephrase my
objection.  Even if there is an agreed upon standard schema as there is for
LDAP, you are still constrained by the expressive limitations of the schema
language.  This is as true for SPML schema as it is for LDAP.  My example,
you didn't seem to notice,  was stated in SPML schema, not LDAP schema - I
know the difference even though it is slight.  Since we're on the subject,
SPML even loses some of the expressiveness of LDAP schema in that there
seems to be no way to specify syntax or matching rules.  Not that I'm in
love with those concepts because, again, they are defined in documents that
must be ferreted out (or known about beforehand)  rather than being
available for immediate interpretation by tools.

As far as a root DSE and controls go, I would argue that if there is no way
for a tool to determine any metadata about an element of the protocol then
it doesn't belong there.  I would ask the same question about determining
the schema for an entity in the absence of a root DSE or the requirement
for a subschemasubentry attribute.  Does SPML mandate the use of
subschemasubentry or is SPML schema simply declarative and how you go about
getting it outside the scope of the spec?

As I'm sure you know, we also make extensive use of directory based
protocols for provisioning and I don't see the need to restate that or
OpenNetwork's commitment to DSMLv2.  What would be more interesting to me
would be for you to assure me that you have never run into any limitations
in your use of DSML or LDAP:  No XML documents as attribute values;  No
Java serialized objects as attribute values because you were just stuck and
there was no other way.

You seem to be completely missing my point about WSDL. and I can certainly
be more specific, but I also like the direction some other specifications
have gone with their definition of the basic message schema in XML-Schema
and then a separate binding into WSDL.  That's exactly what I would like to
see.  Those specifications have targeted their messages to the domain and
publish the interface using WSDL. To state that you are following that lead
is to ignore the fact that you are repackaging a directory protocol which,
to repeat myself again, is the brunt of my objection.

Obviously SPML must go beyond a lot of the existing simple services out
there because it must allow the definition of schema.  This is another
conerstone of my argument and you cannot dismiss it by claiming that
someone could define a class with a particular attribute with a particular
syntax if they want a suspendable account or some other feature.  Sorry but
that doesn't jive with your arguments about semantics and it doesn't
satisfy my need for a provisioning centric API with en expressive schema

The questions I'm asking will be asked by others when you unveil this
proposal to the world at large.  To be honest, the dismissive "don't worry
about it, it will easily work" platitude is OK for me but doesn't win
support when real problems have to be confronted and solved.  As I have
said before, we should be on the same side.

|         |           Jeff Bohren      |
|         |           <jbohren@opennetw|
|         |           ork.com>         |
|         |                            |
|         |           02/27/2003 11:15 |
|         |           AM               |
|         |                            |
  |                                                                                                                              |
  |       To:       provision@lists.oasis-open.org                                                                               |
  |       cc:                                                                                                                    |
  |       Subject:  RE: [provision] Reuse in SPML                                                                                |
  |                                                                                                                              |


I apologize for not being clear on this, but root DSEs are not part of
SPML. Although the control element is allowed as past of the DSMLMessage
definition, this is outside of the scope of SPML. If that bothers you we
could easily remove the reuse of the DSMLMessage type. Would you like me
to propose that at the next meeting? It would have no impact on the spec
to do that. Also, we do not use LDAP Schema in SPML. There is an SPML
Schema mechanism.

I'm sorry, but I still don't see the value in throwing away what we have
so far to start from scratch along a path that may never yield any
useful results. I would still rather go with something I know will work.

Could you do provisioning with just DSML v2? Absolutely, and OpenNetwork
Technologies will continue to support that in addition to SPML. In fact
my original "SPML based on DSML v2" proposal was much closer to DSML v2
than SPML is today. As committee we added the additional functionality
to support areas that DSML v2 was deemed insufficient.

The SPML effort is not intended to be limited to SOAP/HTTP. That is one
of two supported bindings (the other being the File Binding) in the 1.0
spec. There will probably be other bindings defined post 1.0. If we
build the spec around WSDL, then we are limited to the SOAP/HTTP
binding. I don't find that acceptable.

If you believe that WSDL/XML Schema is the right solution, go ahead and
use it. The PS TC has published a XML Schema for SPML and will likely
publish a WSDL definition as part of the SOAP/HTTP Binding.

Note that the approach we are taking for SPML of defining the protocol
in the document body schema (with supporting normative restrictions)
rather than as WSDL/XML Schema is the same approach being taken by DSML,
SAML, XKMS, OMI, UDDI, etc. Are there any standards bodies taking the
approach of defining the protocol in terms of WSDL/XML Schema only? It
is an interesting idea, but it seems risky to me at this stage.

The intention is that WS-Security be used with the SPML SOAP/HTTP
Binding. That is why we explicitly avoided dealing with authentication
issues in that binding. There will be recommendations around WS-Security
in the SOAP/HTTP Bindings document.

The SPML Batch Request is not intended to imply transactions, although
an implementer could certainly make them transactional. Instead it is
intended to support the asynchronous request/response model, something
that DSML v2 lacked.

Now for the suspend/restore example. The PSTC (or someone else) could
define a standard schema that defines an object class for accounts that
can be suspended. For this example, call it suspendableAccount. This
class would define an accountStatus attribute. Any PST that supports
suspendable accounts would add this object class and a parent class of
the PSTs object class.

The PSP, when trying to suspend an account would look to see of the
account type had suspendableAccount as a parent class. If it did, it
would use the accountStatus attribute.

This is just speculation, so don't get hung up on the details. I'm not
sure how this problem will actually be solved, but it is easily

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc

-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Thursday, February 27, 2003 12:30 PM
To: Jeff Bohren
Cc: Conrad Agramont; provision@lists.oasis-open.org
Subject: RE: [provision] Reuse in SPML

You'll have to tell me how LDAP schema conveys the concept of suspending
account using a specific value of an arbitrary attribute like
accountStatus.  Let me try.  An LDAP (SPML) schema for accountStatus
look roughly like:
<AttributeDefinition xmlns="urn:oasis:names:tc:SPML:1:0:schema"
name="accountStatus" multivalued="false" type="xsd:string"/>
OK, so I can look at at this document and see that there is a
attribute called accountStatus that is a string.  Yesterday we were
about semantic predictability, this tells me nothing about semantics and
just a little about syntax.  I wouldn't call that successful.  Compare
instead what some kind of service level API definition might look like,
were we instead to use XML-shema:
<xsd:attribute name="accountStatus" use="optional">
            <xsd:restriction base="xsd:string">
                  <xsd:enumeration value="supend"/>
                  <xsd:enumeration value="restore"/>
Now I'm not suggesting that this is a real part of some API, it's just
example - I could just as easily have concocted a WSDL API that included
suspend method.  My point is that already, to a human reader, this
some meaning.  The semantics of this attribute leap out of the page.  In
addition I have tools that can generate classes from this, in many
langauges, that I can use directly and that now model the domain.  You
throw examples like SNMP around until we're all blue in the face, and
counter examples like CIM but you know as well as I do that the success
failure of a given specification relies heavily on adoption, momemtum
dare I say, fashion as much as anything else.  I'm not saying that's
happened in the cases you mention but if you really want some examples
not look at WSDL?  Is Microsoft barking up the wrong tree with .Net I
wonder?  IBM's emphasis on Web Services must be misdirected.  What about
the explosive growth of Portal servers? What about the body of work that
growing up around these standards such as WS-Security, WSTransactions?
list goes on.  It's my belief that the SPML can ride this wave and be
counted or look backwards to SNMP and LDAP, use the limited schema
facilities they have to offer, and be regarded as difficult and
Why should I have to use different tools and switch cognitive gears when
I'm faced with dealing with SPML when I'm merrily integrating disparate
systems that rely on WSDL/XML-Schema?

You keep referring to the simple, proven model that works and yet there
so many things, other than schema, carried over from LDAP/DSML into the
current proposal that are not simple nor have they proven to be useful
provisioning.  You never answered my question about server requirements
a root DSE.  How will I discover what controls are supported by a PSP?
should I have to?  Even if I do, what does a control mean?  How do I get
even a syntactic description of one, read an RFC? The semantic behaviour
batch requests in SPML differs from DSMLv2 as far as I can tell because
are implying transactional semantics in a batch request which, correct
if I'm worng, is not part of DSMLv2.

If acceptance is what you are after then a specification that fills the
vacuum for a provisioning API is what we should be aiming for.  If SPML
differs only slightly from DSMLv2, and raises more questions about
inappropriate directory type behaviour and limited schema, why should I
adopt it in favour of DSMLv2?

|         |           Jeff Bohren      |
|         |           <jbohren@opennetw|
|         |           ork.com>         |
|         |                            |
|         |           02/27/2003 05:13 |
|         |           AM               |
|         |                            |

  |       To:       Gearard Woods/Irvine/IBM@IBMUS
  |       cc:       Conrad Agramont <conrada@microsoft.com>,
provision@lists.oasis-open.org                                      |
  |       Subject:  RE: [provision] Reuse in SPML


There is a very easy way to convey the meaning of concepts like
accountStatus. It can be done through the use of standard schemas.
Although LDAP has successfully used that concept, the best example I
have for that is SNMP. SNMP has a simple protocol that defines
operations and data types. True interoperability is not achieved in SNMP
via the protocol but through the use of standard schemas that define
what the semantics of protocol for specific services.

This approach has led SNMP to achieve the highest level of adoption and
interoperability of any management protocol while it's more fully
feature competitors such as CMIP are dead.

By counter example, the WEBM/CIM specification from the DMTF does model
real world objects. Although there are a lot of things I like about
WEBM, and it has been implemented by MS and a few others, it has not
achieved widespread industry adoption. And I don't expect it to do so
anytime soon. WEBM is everything you describe, but no one wants to
implement it.

I would rather stick with a simple proven model that we know can work
rather than try to invent a new concept that may never be accepted. Sure
there are limitations, but by using proven model we know what those
limitations are and can plan accordingly. If we start from scratch, we
most likely won't know what the limitations are until it is too late.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc

-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Thursday, February 27, 2003 2:35 AM
To: Jeff Bohren
Cc: Conrad Agramont; provision@lists.oasis-open.org
Subject: RE: [provision] Reuse in SPML

I know you've worked hard on this spec and I'm sorry to drop in at the
minute only to be criticial.  After all, the window for submissions came
and went and there was a resounding silence from our corner.  In the end
though, competitive pressures aside, I think we're all on the same side.
We all want something that will work, as you point out, and beyond that
my part, I want something that fits in with the tools and technologies
I anticipate I will be using over the next few years.  I would prefer
it be as elegant as is possible in a design by committee scenario, as
and simple as possible so that it can be understood and implemented, and
appropriate to the domain as a service interface should be.

There are many people on the committee I'm sure who have direct
experience with directory based protocols in provisioning.  My
with them in a provisioning context is what leads me to conclude that
more by chance and, as Conrad said, for lack of something better that we
use them at all.  Of course they work.  We're engineers, we make things
work even if it takes pieces of string and double sided tape but that's
the point.  The point is that we have the opportunity, the tools, the
technology and the market interest to make something better.
like X.500 were created way back in the big iron days to solve a
problem.  The fact is that it wasn't a provisioning problem, it was a
directory problem.  Provisioning is becoming a term that people
more and more as something that is distinct, and something that has
importance.  Building a management or provisioning interface into
is a pivotal part of the product's ability to integrate into your
enterprise and thereby part of its appeal and value.  Of course XML is
as the answer to all integration problems but we can be more specific:
WSDL and XML-Schema are here to stay because there is huge momentum
them in the form of your second point, industry acceptance, which
translates into toolkits, and a growing set of interoperable and
comlementary specifications that everyone can take advantage of to make
their job easier and their systems more robust.

I like your semantic predictability argument despite its cognitive
dissonance.  All joking aside, you seem to be assuming that it's not
possible to create an interface that exhibits an equal measure of
predictability on an equally predictable model.  In fact, I would argue
that a more predictable model and interface could be created when the
entities involved reflect real world objects rather than a set of
attributes and values, and operations that reflect provisioning
rather than add, delete, modify.  Take a specific problem common in
provisioning systems: suspending an account.  I know some provisioning
systems that use an attribute modification (say, the setting of an
attribute to some value, e.g. accountStatus = "1") to effect this
operation.  In the world of LDAP and LDAP schema, there is no way to
communicate this semantic meaning and the current SPML will continue
tradition.  Where is predictability when I buy multiple products with
of documentation and have to wade through it all to discover how to
an account?  You can see where I'm going.  Comprehensive schema,
self-describing systems, and APIs that make sense to humans are all the
rage for good reason and I think you've hit the nail on the head - it's
semantic predictability.

I'm not suggesting that SPML be a rehash of WSDL or consist exclusively
extended operations, that wouldn't do either.  But there is a definite
that we're all feeling for a usable provisioning API that will fit
with the Web Services we're using and creating and is all about
provisioning.  The question that we're being asked as practitioners in
field is what should that look like?  X.500 wouldn't be my answer.

|         |           Jeff Bohren      |
|         |           <jbohren@opennetw|
|         |           ork.com>         |
|         |                            |
|         |           02/26/2003 07:08 |
|         |           PM               |
|         |                            |

  |       To:       Conrad Agramont <conrada@microsoft.com>, Gearard
Woods/Irvine/IBM@IBMUS                                      |
  |       cc:       provision@lists.oasis-open.org
  |       Subject:  RE: [provision] Reuse in SPML


I personally feel that everyones views should be considered regardless
how much time they have spent working on the TC, so long as they are
serious contributions. If there are a number of people that feel that we
have accomplished so far is not the right solution, we should take the
to work this out. Even though I have put a lot of work into this, I
want to put forth a specification that only gets adopted by two or three
companies. Of course the price for this is to miss the oportunity for a
Burton Catalyst Interop event.

Darran, should we add time to Monday's agenda to talk about Gerry and
Conrads concerns?

Having said that, let me outline my reasons that I think we do have the
right solution. It may not be the best solution, but I doubt we as a
committee would ever find the best solution anyway. Committees never
the best solution for anything. Anyway, here is my case for our current

Practicality - I know from personal experience that the DSML/LDAP model
works for provisioning. It is as simple as that. It works. We can invent
lots alternative solutions, but if we built a spec around one of them,
confident would we be that after the spec is ratified, it would work in
practice? We currently have a model that has been demostrated to work in
practice, not just in theory.

Industry Acceptance - forget about DSML for the moment. The concept of
representing accounts as name/value pairs is widely accepted among the
types of resource that need to be provisioned. JNDI has achieved
usage, and not just for LDAP. LDAP is being adopted at an astonishing
MS seems to be slowly moving all of it's major server identity stores to
(at least as an option). Most commercial IT systems now support LDAP as
option. Most of the commercial provisioning systems are either LDAP
enabled, support LDAP in some fashion, leverage meta-directories, or
have a
virtual directory front end. DSML itself is starting to gain traction,
a JNDI SP available from Sun, a DSML gateway for AD from MS, a DSML
for eDirectory from Novell, announced DSML support in MMS 3.0, and of
course the DSML based provisioning web service from OpenNetwork
Technologies. And then there are the other XML provisioning
that are LDAP related, such as the Access360 DAML spec and the Novell
DirXML spec.

Theoretical Advantages - one way to look at provisioning is as a
namespace problem. A typical provisioning system maintains an internal
model of the provisioning namespace and synchronizes that namespace with
the external systems. The LDAP model does have inherent limitations, but
those limitations are also it's strength. Because there are limits to
the namespace can be represented and what operations are available,
is semantic predictability of the operations. When a PSP makes an add,
modify, or delete request to a PST, there is predictability as to how
PST will behave. The  PSP should be able to make reasonble assumptions
about the post-operation state of the PST namespace without having to do
reconciliation. This is why I have tried to downplay the extended
By thier very nature the do not have sementic predictability. You could
create a provisioning system that could use any PST web service that had
WSDL definition, but such flexibility would make interoperability very
difficult. Likewise doing everything through extended requests will have
the same result.

Mature Proven Track Record - SPML is derived from DSML v2, which is
from DSML v1,  which is derived fro LDAP, which is a derived from X.500.
X.500 and LDAP both have a long successful track record. Simply put,
work. They work well.

Finally, I would like to pose the question: What do we gain by not using
the DSML/LDAP model?

Jeff Bohren

-----Original Message-----
From: Conrad Agramont [mailto:conrada@microsoft.com]
Sent: Wed 2/26/2003 6:02 PM
To: Gearard Woods; Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Reuse in SPML

             I have also been very absent from much of these
and much
             of it has to do with the discussion in this thread.

             I don't think that the requirement of matching the model to
DSML closely
             for mindshare reasons is justified for what needs to be
As I've
             stated before in previous meeting, we should be focused on
providing a
             model that fits the need directly and not derail the
innovation by
             trying to align too closely another standard that is not
offering a
             great deal of leverage.

             I also understand that this type of functionality is
             OpenNetwork's product today, but does this mean that it's
             model that the entire industry should be moving towards?
             decision to leverage DSML could be contributed to the lack
             model being readily available.  So by providing an SPML
that looks
             like DSML might be great for OpenNetwork or anyone else
has done
             the same, but for the future of SPML is this the right way

             Now this may be a bit late in the game, but I agree with
Gearard that we
             should really put a little bit more time to decide if this
the model
             that we want presented to the industry as our
for a
             provisioning schema.

             Conrad Agramont
             Program Manager
             Microsoft Corporation

             -----Original Message-----
             From: Gearard Woods [mailto:gewoods@us.ibm.com]
             Sent: Monday, February 24, 2003 10:46 PM
             To: Jeff Bohren
             Cc: provision@lists.oasis-open.org

             Thanks for the reply Jeff and of course I agree with you,
             well understood and there are plenty of examples of
provisioning systems
             that take advantage of directory-centric protocols such as
DSML (and
             for that matter).  I don't want to turn this into a big
when you
             guys are so close to finalising something but as a
             user/implementor of SPML, I want to put in my two cents in
attempt to
             make sure that we don't end up suffering from the
             directory-centric protocols that we, and you, have
for so
             As I said, I can understand the argument for filters, and
             minimal (an argument against coupling I thought, and what
about those
             controls?).  What pains me more is the schema limitations
             particularly when you want to talk about more complex
             attributes and values.  I know that the committee
             limitations of directories - the enhanced schema for
             reflects that.  In my mind though, the ability to specify
operations is
             only one side of the coin (and I would argue that there are
             tool-friendly ways of doing it), complex types is the

             You'll have to forgive me but I don't buy the midshare
argument for
             but the most high level marketing types.  There are plenty
             for this you need look no farther than the wealth of Java
APIs, where
             developers are more than happy to adopt unfamiliar concepts
when the
             match the problem, or at least model it adequately.  And I
don't have to
             point out to this group that the world is tooling up
for WSDL
             XML-Schema based Web Services.  Portal servers that
             their essential lingua franca are being adopted like hot
and those
             just require an appropriate API, not a familiar one.  I'm
being a
             complete nay-sayer here, I think that it could be easy to
transition to
             this kind of approach if there is a will and we bear it in
mind before
             commit anything to stone.

             |         |           Jeff Bohren      |
             |         |           <jbohren@opennetw|
             |         |           ork.com>         |
             |         |                            |
             |         |           02/24/2003 06:32 |
             |         |           PM               |
             |         |                            |

               |       To:       provision@lists.oasis-open.org
               |       cc:
               |       Subject:  RE: [provision] Reuse in SPML


             From the OpenNetwork Technology perspective, the DSML
             quite nicely. We already have a provisioning web service
based on
             DSML (
             will be a natural progression to extend this to support
as well.

             Although DSMLMessage is extended, it is really not core to
             concepts and could easily be replaced. What is leveraged in
SPML is:

             Search Filters

             That may not seem like a lot, but the cost is very low, so
not? We
             coudl very easily replicate the parts of DSML we are using
no depend
             it any more, but I don't see any tangible benefit in doing

             Of course the real benefit is not is saving a few element
             in the mind share that is gained by explaining Provisioning
terms of
             model than many already understand. The concept of
             using LDAP like constructs seems to be a good fit for most

             Jeff Bohren
             OpenNetwork Technologies

                          -----Original Message-----
                          From: Gearard Woods
                          Sent: Mon 2/24/2003 5:29 PM
                          To: provision@lists.oasis-open.org
                          Subject: [provision] Reuse in SPML

                          I've been absent from the discussion for a
so I
             apologise if this is
                          an old chestnut but following on the heels of
             question about
                          batch operations in SPML, I'd like to ask the
committee if
                          of maintaining the dependency on DSML are
             I can
                          certainly understand the argument for the use
the DSML
             Filter, athough
                          that could be adressed if necessary, but I'm
             about the use of
                          DsmlMessages.  As everyone knows, DsmlMessages
             encapsulate a set of
                          controls and an optional request ID.  This is
such a
             class and all
                          of the SPML messages are derived from it so it
seems to me
             that SPML is
                          building in a dependency for very little gain
this case.
             This also
                          raises the issue of discovery of supported
controls, as
             LDAP/DSML.  In
                          LDAP of course, the specification calls for
server to
             provide a root
                          DSE where vendors generally publish the set of
             controls and
                          extensions.  I notice that the SPML schema
includes the
             ability to define
                          extended operations but I don't see a place

                          I've been trying to catch up on the minutes of
the meetings
             that I've
                          missed but I don't see any discussion so far
the use of
                          schema language.  Propagating an LDAP style
schema language
             when the
                          specification is written in a more expressive
             XML-Schema, seems a
                          little anachronistic to me.  I'm sure there is
             I'm sure there
                          was discussion on the subject, but it appears
             that a lot of
                          time could be saved by re-using XML-Schema
             re-defining another
                          schema langauge in XML-Schema.  This leads to
             question on
                          appropriate re-use and that is the definition
             operations in a
                          world where considerable effort and tool
has been
             into the
                          WSDL.  For that matter, it seems likely to me
that the SPML
             might be
                          frequently used within an WSDL context.  In
case, the
             batch request
                          and response mechanisms adopted from DSML
seem very
             useful and
                          extended operations would more naturally be
defined using

                          Again, apologies if I'm covering old ground,

                          To subscribe or unsubscribe from this elist

             To subscribe or unsubscribe from this elist use the
             manager: <http://lists.oasis-open.org/ob/adm.pl>

             To subscribe or unsubscribe from this elist use the
             manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC