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] Simple example scenario



Gerry,

Just to be clear, your proposal for filtering is to use the XQuery 1.0
specification as defined by the W3C? It looks like that is what you are
proposing, but I just want to make sure I have it right.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 

-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com] 
Sent: Wednesday, March 12, 2003 12:27 AM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example scenario





Jeff,
I think it's in there in section "6 querySubscriptions".  It's easy to
miss
and I have to admit that there's an error in it - the example in the
package that I sent out is missing quotes.  It looks like this:

...
            <query
xmlns="urn:oasis:names:tc:SPML:0.1:provisioning:spmlquery">

<select>//parameters/ns1:EMailAccount[ns1:address='wjl@tiny.com']</selec
>;
...
Gerry




|---------+---------------------------->
|         |           "Jeff Bohren"    |
|         |           <jbohren@opennetw|
|         |           ork.com>         |
|         |                            |
|         |           03/11/2003 06:11 |
|         |           PM               |
|         |                            |
|---------+---------------------------->
 
>-----------------------------------------------------------------------
-------------------------------------------------------|
  |
|
  |       To:       Gearard Woods/Irvine/IBM@IBMUS
|
  |       cc:       <provision@lists.oasis-open.org>
|
  |       Subject:  RE: [provision] Simple example scenario
|
  |
|
 
>-----------------------------------------------------------------------
-------------------------------------------------------|




Gerry,

Thanks for updating this example. But, I do not seem to see any example
of
what the select element in the ProvisioningQuery element would look
like.
Is there an example that I missed?

Anyway, could you post an example of the select statement as it applies
to
the Tiny Telecom example? Thanks.

Jeff Bohren

             -----Original Message-----
             From: Gearard Woods [mailto:gewoods@us.ibm.com]
             Sent: Tue 3/11/2003 8:02 PM
             To: Jeff Bohren
             Cc: provision@lists.oasis-open.org
             Subject: RE: [provision] Simple example scenario







             Jeff,
             I've attached an updated scenario implementation which now
includes a
             filtered search.  The scheme that I've adopted for purposes
of
this example
             uses an iterator model to traverse arbitrarily large result
sets.  In the
             context of this kind of Web Service, particularly for
RA-PSP
interaction,
             I'm not sure that this has great utility since the
overriding
requirement
             will probably not be to suck millions of
accounts/users/objects from the
             service but to interact with the limited set to which the
RA
is authorized.
             In any case, this should meet the stated scalability
requirements - in the
             true sense of the word.
             Gerry

             (See attached file: query_scenario.ZIP)



             |---------+---------------------------->
             |         |           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]