[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Simple example scenario
Gerry, Storage is not the issue I am discussing. I do agree with you that representing state and lifecycle information would be very useful in SPML. I have never felt otherwise. But state and lifecycle are more complicated than described in your current proposal. Let's talk about state for the moment, which is the simpler of the two. I could see at least two approaches to this problem, one I will call "Standard Schema Based" and the other I will call "Protocol Based". The Standard Schema Based approach is to define one or more standard SPML schemas that define state attributes for object classes that can be inherited by vendor specific objects. The schemas would define the data but would be coupled with normative definitions as to what the semantics of those attributes mean. This is exactly the approach taken with standard SNMP MIBs so there is a proven model to draw on. LDAP also uses this approach. The Protocol Based approach would be similar to the one in your current proposal. In this approach the SPML protocol would include explicit state elements. Where I would differ from your approach is to not represent the semantics of those states in the XSD file as enumerated strings, but to put in a more flexible framework so that vendors can define state information that is appropriate for their product. Actually these issues are similar to the billing and workflow information issues we have discussed at previous meetings. We decided that although both of those would be useful to represent in the protocol, coming up with a good solution would not be feasible in the 1.0 timeframe. We also decided that in the short run (i.e. 1.0 spec) those issues could be solved using the SPML extensibility features. One more point. The Standard Schema Based approach is not fundamentally different from your approach, but it is more flexible. In your approach, you define state as being: <restriction base="string"> <enumeration value="suspended"/> <enumeration value="active"/> <enumeration value="locked"/> <enumeration value="terminated"/> <enumeration value="pending"/> <enumeration value="created"/> <enumeration value="requested"/> <enumeration value="unavailable"/> </restriction> This is in itself is meaningless without normative text that defines what each of these enumerated values means. How is this different from defining a standard attribute using the current SPML specification, with normative text that defines what the different values for that attribute mean? Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Wednesday, March 12, 2003 11:48 AM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] Simple example scenario If not in an XSD file then where? A Word document? I'm not sure we're even considering the same problem frankly. Provisioning is more vertical than horizontal in my mind. We're not here to define a data storage mechanism, we're here to define a provisioning mechanism. We can keep going around in circles on this point but I think we're reaching the limit of useful argument. I'm certainly at a loss to even guess at your motivation. Gerry |---------+----------------------------> | | Jeff Bohren | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/12/2003 05:14 | | | AM | | | | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: provision@lists.oasis-open.org | | 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> ---------------------------------------------------------------- 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]