[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Simple example scenario
I also believe that there is great value in explicitly representing
state and lifecycle information. I think there would be a lot of value
in adding to the SPML standard. That does not, however, mean that it
must be added as fixed definitions in an XSD file. It also does not mean
that it should only be done as standard attributes. There are an
unlimited number of different approaches to this problem.
If we continue with the current SPML approach, I would want to keep
state and lifecycle management as an open issues to address in the next
revision of the specification. I do think it is important, but I want it
to be extensible and flexible. To me, fixed but optional doesn't cut it,
even as a starting point.
As for motivation, you would be mistaken to attribute my opinions to
being PST focused.
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Wednesday, March 12, 2003 1:05 AM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example scenario
Jeff,
I was only talking about "subscription". Didn't we have this argument
before when we compared methods? The need, or lack thereof, for
lifecycle
management/description is pretty much indicative of our different views
on
what this API really is or should be. They're optional in my schema, so
I
think you're overstating it when you say it's limiting. There's nothing
to
stop you encapsulating any other target state, such as your
DirectorySmart
user state, if you want to. The benefit of having these in the model is
that you then have what you having been asking for all along: semantic
predictability. If you don't specify them then they're not in the model
and they have no meaning.
I think the difficulty we're having is that you wish to pare down
everything to attribute and values and then move higher level models
into
the realm of the PSTC in the form of standard schemas. How very LDAP of
you. My argument of course is that everything should be self-describing
and the higher levels, including a sophisticated model focused on
provisioning, should be available directly in the schema as written and
we
should disregard the low level model. I know this repitition is getting
tiresome but I'm starting to believe that the fundamental reason that we
think so differently about this is because we really are on different
sides. I'm on the side of the client talking to a PSP in most of my
thinking because this is the kind of service I need today. I think that
your focus is on the PST. Is that fair? If it is fair does that
perspective help us in any way?
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/11/2003 07:27 |
| | PM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard Woods/Irvine/IBM@IBMUS
|
| cc: provision@lists.oasis-open.org
|
| Subject: RE: [provision] Simple example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
If you are looking for terms that are not overloaded with other
meanings,
then why not use "create", "modify", "delete", or "query"? Or why not
"add", "update", "remove", or "search"? How would those terms imply
anything other than what you are proposing?
I agree that the concept of state and lifecycle is important for many
applications. These concepts can easily be supported by the current SPML
specification without explicity representing them in the protocol. State
and lifecycle information can be added to the specific schema for the
entities for which they are relavent. There is no need to assume a
single
fixed set of state and lifecycle attributes and values. This seems
rather
limiting to me.
In fact the DirectorySmart user representation does have state
information,
but there is more than one state attribute. There is one state attribute
that describes the user's account state and there is another that
defines
the users password state. For instance a DirectorySmart user could be a
valid user, but needs to reset his password on the next login. Both of
these states are important, and they both can not be represented
directly
in your proposal.
Now I'm not trying to imply that the SPML schema be written to just to
support OpenNetwork Technologies or any other vendor. But if I see how
there would be a problem supporting an approach in our product, then it
might be a problem for someone else who is not on the committee, but may
need to implement the final specification.
Jeff Bohren
OpenNetwork Technologies
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Tue 3/11/2003 5:11 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example scenario
Jeff,
I just received your implementation of the scenario in the
current approach
and I have to admit that it looks like you've done a very
comprehensive
job. I'd like to spend some time with it over the next
couple
of days and
perhaps it might be useful if we both summarised our
perspectives on the
comparitive advantages and shortcomings of each based on
the
exercise. I
think this would benefit committee members who don't have
the
time to wade
through a lot of XML, and would help to highlight the
important points of
our recent discussions with these concrete examples at our
fingertips.
Since you feel so strongly about the need for filtered
searches, I'll post
an updated set of examples with a filtered search to
redress
the balance
and provide a better point of comparison.
To address your confusion about suspending accounts, I
think
the problem
comes down to misunderstandings about the schema. It
appears
to me that
you have misinterpreted my proposed schema and arrived at
the
conclusion
that all "subscriptions" are accounts and that the model
only
supports
entities that can be suspended/locked/terminated etc. I
was
not dismissing
the value of being able to express these notions at all, I
was
trying to
make light of your continued misinterpretation.
Personally, I
feel the
idea of state and lifecycle are very important in a
provisioning model.
You obviously feel differently but regardless, there is
nothing in the
schema that requires that these features be used. Perhaps
the
problem is
the name subscription although I have to admit that it's
hard
to find a
term that is not overloaded with even more meaning so I
think
I'll stick
with it for now.
On the general concerns expressed in your previous message,
I
want to point
out that I appreciate what I'm asking the committee to
consider but that
makes this exercise no less valuable in my opinion. It's
encouraging to me
that the attendance at the committee meetings seems to have
grown and
includes more interested parties than even a few months
ago.
This is not
at all surprising because of the increased profile of
provisioning of late,
and the entry of large interests such as IBM into the
market.
Beyond that,
there is a real need for a solid provisioning service
definition as we're
all too aware. The discussion we've been having is the
start
of what, I
imagine, will be a continued wave of questions regarding
approach and
current technology trends as the spec undergoes more
scrutiny.
You and
OpenNetworks have obviously, as you have frequently pointed
out, committed
to DSMLv2. There are others, Tivoli among them, who have
immediate
problems that cannot be addressed by this kind of solution
without, as I
frequently point out, jumping through a lot of
uncomfortable
hoops. As we
near the end of this exercise, and since you bring it up, I
should say that
I feel that the responsibility of the PSTC is not to Burton
or
any single
member of the committee but to the community of consumers
the
PSTC's
product. If the community is not served then any number of
analyst events
won't matter.
Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/10/2003 06:52 |
| | PM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard Woods/Irvine/IBM@IBMUS
|
| cc: <provision@lists.oasis-open.org>
|
| Subject: RE: [provision] Simple example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
I am not talking about returning 30 million records in a
search response.
That would be a search WITHOUT a filter. Which is, of
course,
what I am
trying to avoid. The scalability I am referring to is the
ability to look
for a set of records, in a large record set, that match a
specific
criteria. This has nothing to do with directories and has
everything to do
with provisioning (and is one of our agreed to use cases).
Unless you think
that provisioning only means a client pushing data to a
server, then this
is a provisioning issue.
Handling large data sets is an entirely different issues.
The
current SPML
specification does not address this issue, and neither does
your proposal.
I would like nothing more than to stop talking about
searches.
Just
supplement the Tiny Telecom example you posted with sample
of
a scalable
search mechanism. For this example just assume scalable
means
to find some
small number of accounts that satisfy a search criteria.
You
can make it as
"Provisioning centric" as you like. Work it in any way you
like, just show
me how it is done.
Note that all the previous paragraphs discuss provisioning.
Now I am confused about suspending accounts. You created
the
ProvisioningSubscriptionState element in you proposed
schema
to represent
the state of accounts. First you say that explicitly
representing such
things in your protocol is one of the features that makes
if
more
"Provisioning Centric", and now you seem to be saying that
it
was just an
unimportant example. Which is it? Is explicity representing
account state
part of your proposed protocol or not? If it is part of
your
protocol, then
tell me how you handle things that can not be suspended (or
locked, or
terminated). This is part of the provisioning discussion
you
want to have.
I do understand your concerns and I agree with many of
them.
But simply
put, you have yet to convinced me that the current approach
is
unworkable,
insufficient, or will not be adopted by the industry at
large.
You are
asking me to do several things: first flush the last 6
months
of work the
committee has done, give up on the Burton interop, give up
a
solution that
I have seen work in practice, and implement your proposed
solution in the
OpenNetwork Technologies provisioning web service (note
that
this
implementation will require some sort of search
capability).
If you think
raising these issues means I am ignoring yours, you are
wrong.
I will
continue to raise these issues as they are important to the
decision at
hand.
Jeff Bohren
OpenNetwork Technologies
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Mon 3/10/2003 5:21 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example
scenario
Jeff,
I should really have come up with some example
other than
suspending an
account - we seem to be getting stuck on that.
I
am equally
open to
debating search behaviour but the other points
that I'm trying
to impress
upon you seem to be falling on deaf ears. But
let's address
search anyway
and then move on to what I consider to be more
interesting and
relevant
topics. You cannot argue that the currently
proposed search
mechanism is
scalable, particularly if you intend to
support
SOAP. In your
example of a
recon of 15-30 million records, the current
search mechanism
will require
that you collect all of the results, embed
them
in a SOAP
envelope, and
return this huge data set to the client. The
scalability
issues are evident
but I'll enumerate them: memory constraints
on
the PST or PSP
whichever is
performing the search; bandwidth requirements
on
the network;
memory
constraints again on the client that requested
the search once
the results
are returned. In the spirit of cooperation,
let
me suggest
that you
consider RFC 2696 (but you'll need to put
controls back in).
You simply cannot claim that you have solved
the
search
problem once and
for all, that my examples haven't, and use
that
to justify
ignoring my
other complaints. I will address the
implementation of
searching in my
proposed scenario if it comes down to it but
we
need first to
discuss the
model since the model is the central argument.
First though,
I think we
need to dispel this argument that the problem
is
a federated
namespace
problem. If that were the case then I need to
buy a
meta-directory not a
provisioning system and we are all on the
wrong
committee. It
might be
easy to simply say that the current proposal
is a
bottom-up
approach and
that I'm suggesting a top-down approach. My
real
argument is
that we need
to talk about provisioning and what that means
in
terms of a
simple useful
model that integrates well with modern web
services
technology, not how we
simply get an attribute value from point A to
point B. We
need to address
the problem at the right level of abstraction
so
that the
foundation we
build today will continue to meet the needs of
the community
when/if we go
on to address the other apsects of a
provisioning
model such
as
entiltlements, policies and even simpler
issues
such as change
notifications.
I'm not out to win an argument here, I simply
want to do the
right thing.
At this point I don't want to reiterate my
apparently wasted
arguments on
provisioning-centric solutions because I think
my
views are
clear. We can
continue to talk about attributes,
objectclasses,
controls,
DSML search
filters etc. as much as you want. My question
is
when are we
going to
start talking about provisioning?
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/10/2003 11:44 |
| | AM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard
Woods/Irvine/IBM@IBMUS
|
| cc:
provision@lists.oasis-open.org
|
| Subject: RE: [provision] Simple
example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
Let me answer some of this with an example.
In the Tiny Telecom example, the friends and
family account
has up to
ten contacts that can be associated with it.
Since people
could be a
contact for more than one person it makes
sense
that the
contact could
be an independent record. In this case
creating
the friends
and family
account could consist of:
1) Creating or looking up one or more contacts
2) Creating a friends and family account with
references to
the newly
created or existing contacts
This example illustrates two points. First not
everything in a
provisioning system is an account that can be
suspended.
Second,
searching for existing records may be an
important part of a
provisioning process. Note that nothing I say
in
this
paragraph has
anything to do with directories.
Finding existing contacts in a telco
environment
may require
searching
through millions of records. Our current
filtered
search
mechanism will
support this in a fashion that has been
demonstrated to be
scalable in
other deployments.
And of course there is the reconciliation
issue
inherent in
enterprise
provisioning. That requires some kind of
parameterized query
(filtered
search) to be done correctly.
So is some form of parameterized query
(filtered
search) a
requirement?
Not for all systems, but the spec must define
it
for where it
is
required or it not complete. It is certainly a
requirement for
our PST
product.
Could some sort of XML Query be used as a
parameterized query
(filtered
search)? It's a possibility, but I would like
to
see an
example before I
could say whether it was a good solution.
I am willing to keep an open mind on this and
consider all
proposed
solutions, but I am unwilling to agree to a
solution that does
not
include well thought out solution to
parameterized queries
(filtered
searches). I would also judge such a solution
on
how well it
meets our
specific scalability needs (i.e. it must scale
to
15-30
million user
populations).
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Monday, March 10, 2003 2:03 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example
scenario
Jeff,
Although we've probably covered most of this
in
the call this
morning, I
imagine that we'll want to keep this thread
going
through the
week so
I'll
address the questions that you have here.
Filtered search I think we've agreed is made
more
difficult
when the
schema
becomes more complex. My approach to this
problem is twofold
and I
think
we've touched on these before. First, if
really
required by
the PST
requirements and use cases then I would argue
a
solution could
be found
in
one of the XML query langauges currently
available.
Alternatively, I
would
question the need for a full blown query
language
at all
considering the
use cases. I tend to favour this latter
position
and think
that the use
cases could be satisfied with a set of methods
and schema
elements
targeted
to querying aspects of the model. I can
expand
on this if you
want some
more concrete examples.
PSP-PST communication doesn't differ
significantly from RA-PSP
communication in this approach. The model
would
be the same
but
obviously,
it would be common to have the PSP support
many
targets.
I disagree with your point about the state
implying accounts,
the
enumerations seem relatively general to me.
If
you are
arguing that
they
are not extensive enough then I would agree
that
there is
probably room
for
more.
As we discussed in the call, since we are
satisfying the same
use cases,
our operations (which to me embody the use
cases)
will appear
very
similar.
Where the significant difference lies is in
the
model used in
theses
conversations. As far as the target being
semantically
equivalent to an
objectclass I would have to say that no, a
target
is a
distinct entity.
A
target has identity which an objectclass does
not. An
objectclass
implies
type - a target encapsulates schema. I think
there is a
significant
difference here.
The current request schema message satisfies
the
query target
schema
uses
cases as does the getTarget method in my
example.
Constraining the schema is an important point
and
here I think
is where
we
diverge most in our approaches and general
philosophy. I
don't see the
need to constrain the schema any more than
LDAP
or the current
approach
dictates what specific objectclasses may be
used.
I think
I've argued
before that the target schema is a contract
and
the PSP or RA
on the
other
side of the relationship needs to understand
the
language of
the
contract,
as identified by the schema namespace. My
examples provide
only for
the
ability to declare what schema element
represents
the type of
the
target.
As I mentioned earlier too, I don't want to
even
restrict the
schema
language to XML-Schema. It should be possible
to
use other
schema
languages, a good example might be Oasis'
Relax
NG.
The philosophical difference at the root of
the
schema
argument is
critical. My view is that the SPML should be
a
vehicle for
the
communication of provisioning-related
information. This does
not extend
to
constraining the target schema which should be
opaque to the
provisioning
system. The SPML only provides the
provisioning
model not the
target
model.
Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/10/2003 04:43 |
| | AM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard
Woods/Irvine/IBM@IBMUS
|
| cc:
<provision@lists.oasis-open.org>
|
| Subject: RE: [provision] Simple
example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
I am just starting to look at the scenario
this
morning, so I
don't know
how much of an example I can have back to you
by
today's
meeting.
Looking at it, I do have some concerns and
questions.
Concerns:
My biggest concern is that you do not show an
example of a
filtered
search. This scenario should include it
somehow.
This scenario does not show an example of the
communication
between a
PSP and a PST. That should also be included.
The ProvisioningSubscriptionState type implies
that all SPML
will be
used for is for provisioning accounts, and
further, that those
accounts
will support the enumerated states. I don't
believe that these
assumptions are valid or add any value.
Questions:
Is there any semantic difference between
createSubscriptionRequest and
addRequest? Likewise is
modifySubscriptionRequest
the same as
modifyRequest and deleteSubscriptionRequest
the
same as
deleteRequest?
Using the word "subscription" would seem to
imply
that the
protocol only
supports subscriptions, what ever that means.
Also, is the
"target"
element semantically the same as the
"objectclass" attribute
in the
current spec?
Your query targets concept seems to imply the
same concept as
the
current SPML schema query for object classes.
Is
that correct?
The type ProvisioningTargetType contains an
XSD
schema
element. Is this
intended to be completely open ended? If not
how
is it to be
constrained?
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Friday, March 07, 2003 5:03 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example
scenario
Jeff,
I'm attaching a set of documents that attempt
to
take that
next step.
As I
said in a previous message, I'm punting on the
filtered search
for now
until there is at least some feedback on the
overall strategy
but the
scenario does include provisioning an e-mail
account. To view
the
scenario, unzip the attached file and open
examples/telecom/telecom.html.
Gerry
(See attached file: scenario.zip)
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/04/2003 04:51 |
| | AM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard
Woods/Irvine/IBM@IBMUS
|
| cc:
<provision@lists.oasis-open.org>
|
| Subject: RE: [provision] Simple
example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
Gerry,
I suggest doing email as at least as a part;
since that is
what we
already have examples for in the current draft
specifications.
It should
not be much work to add it to what you have
already laid out.
Anyway, the next step should be for you to
take
the scenario
you suggest
(with an added email component) and lay out
the
specific RAs,
PSPs, and
PSTs and do a rough system design. It does not
need to be in
detail, but
there needs to be enough information that you
can
do the
examples using
your proposed approach and I can do the
examples
using the
current
approach.
There is still one concern, however. I'm not
sure
if this
scenario will
illustrate the filtered search problem. I have
no
problem
doing this
exercise, since it should be very informative,
but I will not
support
changing the current data model without a
corresponding
filtered search
solution.
Perhaps as part of the provisioning process
there
could be
some searches
done for possible pre-existing similar
accounts
at the service
providers?
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Tuesday, March 04, 2003 2:20 AM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example
scenario
Jeff,
I was hoping to take on something a little
more
substantive
but go deep
rather than wide. In other words, rather than
illustrate the
use of
each
of the operations, I'd like to go through the
steps and data
formats
that
you would realistically expect to see used to
describe a
target (or set
of
targets) and provision it, including the SOAP
messages if you
think
that's
appropriate. I don't want to burden you with
a
lot of work or
anything,
I
just want to show what each would look like
soup
to nuts, so
to speak.
I realise that this kind of thing takes time.
If
you feel it
should be
less detailed then let's simplify it but I'd
rather not make
it too
simple.
The important aspects to me are:
- The use of schema since that's one of the
hotspots in our
conversation.
Obviously there are elements in this scenario
that work in my
favour
including cardinality, enumerations, formatted
strings and
complex types
but since those come up in real life I think
that's fair.
- The overall message passing sequence and
content. It's not
clear to
me
which approach would be more chatty or more
verbose in a real
life
situation. Also, this might clarify some of
the
implementation
difficulties since we were debating the level
of
complexity
for an
implementation.
- The composite or aggregate abilities of each
solution.
Would adding an e-mail service to the phone
account be enough
do you
think?
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/03/2003 07:21 |
| | PM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard
Woods/Irvine/IBM@IBMUS,
provision@lists.oasis-open.org
|
| cc:
|
| Subject: RE: [provision] Simple
example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
We use the hosted email service example
throughout the spec
document, so
it
would be a good idea to work that into the
scenario. Perhaps
it can be
an
email service that is accessable from the
handset.
Jeff Bohren
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Mon 3/3/2003 5:09 PM
To:
provision@lists.oasis-open.org
Cc:
Subject: [provision] Simple
example
scenario
Further to our discussion in the
conference call
today, I'd
like to suggest
the following scenario as a
starting
point for a
comparitive
study of the
current SPML and the alternative
approach that we
have been
debating. Any
changes, improvements or comments
are, of course,
welcome.
Gerry
Tiny Telecom provides mobile
phone
services to
California
residents. In
addition to the five types of
basic
account that
Tiny
offers:
personal,
personal anytime, family,
corporate,
and prepaid,
subscribers
are offered a
full range of options which are
generally handled
by Tiny's
partners or
subsidiaries. These options
include
voice mail,
caller ID,
call
forwarding, text messaging, web
access,
long-distance,
handset
options, and
a comprehensive friends and
family
calling plan.
To create
a
basic
account, Tiny requires the
subscriber's full
name, a user
name, a credit
card number (and expiration), and
a
valid
California
driver's
license
number. Subscribers may also
provide an e-mail
address for
notification of
changes in the account policy or
for
opt-in
notification of
special offers
from partners. Basic plans have
a
two year term
and for a
limited time all
new accounts receive free caller
ID
as part of a
promotion
by
one of Tiny's
partners.
The friends and family plan is
one
of the most
popular
options
and allows
subscribers to select a set of 10
contacts that
may be
called
at a
significant discount. To
identify
these
contacts,
subscribers
are required
to provide their names and phone
numbers.
Tiny has implemented a
provisioning
service that
manages
their
basic
accounts and also allows partner
services to be
provisioned.
A typical
usage scenario for the service is
the
implementation of the
self-service
facility on Tiny's website. This
facility is
implemented
as a
Java servlet
that is a client of the
provisioning
service and
goes
through
the following
sequence of operations:
1. Offer the user a selection of
provisionable
services
offered by Tiny and
partners
2. Query the schema of the
services
requested
3. Present a form allowing the
user
to enter the
required
and
optional
fields
4. Submit the provisioning
request
for the
services
5. Notify the user of the success
or
failure of
the request
For the purposes of this
scenario,
assume that
the
subscriber
requests
voice mail, text messaging, and
lists two family
members in
the friends and
family plan. The user also
selects
the default
handset
which
they will
receive by mail. When the
account
is activated,
a password
is
automatically assigned to access
voice mail.
Before the
phone
is received
by the user, they return to the
self-service
website to
check
the status of
the request. The self-service
facility allows
the user to
retrieve details
of the account which now reflects
the fact that
an account
has
been
activated, provides access to the
voicemail
password, and
notifies the user
that the request for text
messaging
has been
denied for
technical reasons.
----------------------------------------------------------------
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>
----------------------------------------------------------------
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] | [List Home]