[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep-cooperating] Federation Protocol Profile
Farrukh, I like where CPP/A is going as well, but do you think we should wait until all of the IPR issues are clarified? I can go either way. -Matt On Monday, May 20, 2002, at 06:14 AM, Farrukh Najmi wrote: > Team, > > Again I am trying to tease apart the conversation into separate more > focused > threads. > > Zach you have mentioned Federation Protocol Profile a few times. Do you > see need > for a CPA between FederationMember and FederationLeader. Since the > CPP/A specs > are not finalized, is it safe to have a dependency on them? I very much > like and > support the work of the CPP/A TC. They are reaching a level of > stability and > maturity that may make this the right time to build upon their work. > > What do others think? Normative dependency on CPP/A or not for V3? Note > that > this is a broader issue for registry-client interface as well. I sense > from > Matt's and Nikola's comments that the answer is Yes. > > -- > Regards, > Farrukh > > > > Zachary Alexander wrote: > >> Farrukh, >> >> I think these are a good start. We could get a lot more granular in a >> FPP >> (Federation Protocol Profile) and support spot markets for "web >> Services" in >> the future. Have you heard of a internet community called Jtrix at >> (http://www.jtrix.org)? There is a write up in the May issue of >> JavaWorld. >> They have a very interesting take on expanding the definition of "web >> services." >> >> zack >> >> -----Original Message----- >> From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] >> Sent: Monday, May 20, 2002 7:34 AM >> To: regrep-cooperating@lists.oasis-open.org >> Subject: [regrep-cooperating] Quality of Service >> >> Zach, >> >> Please note that I am splitting the conversation into multiple threads >> as >> appropriate so that we can have mofr efocused discussions. >> >> I assume by QoS you mean things like: >> >> -Availability guarantees: How often a registry is up or not to fulfill >> federated >> requests >> -Deliver guarantees: Of updates from one FederationMember to another >> >> What else can we think of that is a QoS issue? >> >> I agree that these QoS issues would have to be included in the >> agreement to >> become a FederationMember. Each federation may have its own QoS >> requirements. >> Should these requirements be described as Policy objects in the initial >> infomodel figure I had published? >> >> -- >> Regards, >> Farrukh >> >> Zachary Alexander wrote: >> >>> Farrukh, >>> >>> There is no disconnect. I am in complete agreement with everything >>> you are >>> saying. What do you think about QoS (Quality of Service)? I think >>> that >> QoS >>> functions could play a prominent role in Registry Federation. The >>> need to >>> provide strong SLA support doesn't really exist in a non-Federated >>> environment because you are not sharing control of Registry >>> Resources. The >>> RAAM (Regsitry Agent Access Manager) could be a good place to define >>> and >>> monitor Service Level Agreements (SLA)information. The RA (Registry >> Agents) >>> could pass community health and welfare information up and down the >>> stack >> to >>> the RAAM. This could be its main role. >>> >>> zack >>> >>> -----Original Message----- >>> From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] >>> Sent: Saturday, May 18, 2002 8:14 AM >>> To: zack2@cris.com >>> Cc: Matthew MacKenzie; regrep-cooperating@lists.oasis-open.org >>> Subject: Re: [regrep-cooperating] Kickoff of federated registries work >>> itemforV3 >>> >>> Zach, >>> >>> I think this is an excellent discussion to get our collective >> understanding >>> synched and start with a common base. >>> >>> +1 on the concern about web service bent trivializing ebXML. I am >>> not a >> big >>> fan >>> of the web service hype. While it was good marketing to use the term, >>> I am >>> not >>> the least bit of the opinion that basic web services stack is a cure >>> for >>> aids, >>> world peace and hunger. >>> >>> As Matt can attest to (private joke ;-) ), if the registry specs are >> guilty >>> of >>> any bias or bent, it is that they are very OO centric. The governing >>> principal >>> has historically been that the registry is defined in terms of a set >>> of >>> abstract >>> UML interfaces (RegistryService, QueryManager, LifeCycleManager, >>> RegistryClient). These abstract interfaces may be described in >>> multiple >> ways >>> (e.g. CPP/BPS, WSDL). We chose WSDL only because CPP/A was changng too >>> rapidly >>> then. We expect to have CPP/A descripton to follow. The main thing is >>> that >>> they >>> can be described in some XML form as abstract service interfaces and >>> can >> be >>> also >>> be described in some XML form as concrete service interfaces in >>> specific >>> bindings. One notable point is that each interface is separated from >> others >>> and >>> can be implemented independently. For example, we could have 2 >>> different >>> vendors >>> cooperate to build LifeCycleManager and QueryManager and still expect >> things >>> to >>> work. >>> >>> If we are in agreement that the above OO principals are a good thing >>> then >> I >>> view >>> the RAAL as a new name for what we have traditionally called >> RegistryService >>> interface (the principal interface from which you can get to the other >> more >>> task/role oriented interfaces such as QueryManager, LifeCycleManager). >>> >>>> From my perspective we are in agreement on the need to separate the >>> registry >>> access interface(s) from the registry implementation details. We are >>> also >> in >>> agreement on the need to separate federation related interfaces from >>> the >>> current >>> interfaces for a non-federated registry. However, I get the impression >> that >>> you >>> think that the current design is violating this (agreed upon) sound >>> architectural principal of separation of interfaces. I am not sure I >>> understand >>> where our disconnect is. Maybe it is that you think in terms of >> abstraction >>> layers while I think in terms of abstract interfaces. If that is the >>> main >>> difference then I suggest that we first identify the interfaces and >>> then >> map >>> the >>> interfaces to layers in a layered architecture. >>> >>> What do you and Matt think? >>> >>> -- >>> Regards, >>> Farrukh >>> >>> Zachary Alexander wrote: >>> >>>> Farrukh and Matt, >>>> >>>> My concern is that the Registry Spec seems to be bundled with a >>> webservices >>>> interface and tied to a webservices business model. Not all >>>> applications >>> are >>>> webservices and not all application architectures are client-server. >> This >>>> could very easily affect adoption of ebXML. IMHO, the connection >>>> between >>>> webservices, which has broad vender support, and ebXML trivializes >> ebXML. >>> I >>>> have read webservices articles that have basically said "Why not take >> your >>>> webservices straight." There are a number of different Internet >>>> related >>>> standards projects that are underway that could benefit the ebXML >>> community. >>>> If nothing else these other internet communities could act as second >>> source >>>> opportunities for ebXML. My hope is by formalizing access to the >>>> ebXML >>>> Registry by other internet communities/application architectures it >>>> will >>>> broaden the appeal of the ebXML family of standards. >>>> >>>> The term "Registry Agent Access Layer" is an OSI model metaphor. The >>> lowest >>>> level of the OSI model is the "Media Access Layer." The rationale is >> that >>>> the ebXML Registry should not have to know which internet >>>> community/application architecture the registry is being plugged into >>>> because it is being handled by its "Media Access Layer." I think that >>>> defining this layer will take some work. But, I think that the >>>> implementation of a Registry Agent Access Manager that implements a >>> Registry >>>> Agent Access Layer would go a long way to unbundle the ebXML Registry >> and >>>> the ebXML family of standards. This would also open up the ebXML >>>> family >>> of >>>> standards to new business models. >>>> >>>> zack >>>> >>>> -----Original Message----- >>>> From: Matthew MacKenzie [mailto:matt@xmlglobal.com] >>>> Sent: Friday, May 17, 2002 2:38 PM >>>> To: Farrukh Najmi >>>> Cc: regrep-cooperating@lists.oasis-open.org >>>> Subject: Re: [regrep-cooperating] Kickoff of federated registries >>>> work >>>> itemforV3 >>>> >>>> Farrukh, >>>> >>>> I understand where you are coming from better now. Sounds OK for >>>> me. I >>>> see some issues developing here, such as pluggable protocol support >>>> which probably don't belong in this group...even though I really >>>> would >>>> like to pursue them. >>>> >>>> -Matt >>>> >>>> On Friday, May 17, 2002, at 08:59 AM, Farrukh Najmi wrote: >>>> >>>>> Just to clarify, I am talking about FederationLeader and Federation >>>>> meber as >>>>> two new interfaces that may optionally be implemented by a registry >> (in >>>>> addition to the required QueryManager and LifeCycleManager >> interfaces). >>>>> For >>>>> implementations migrating from V2 to V3, most of the new stuff would >> be >>>>> encapsulated in teh implementation of these two new interfaces. >>>>> >>>>> While the two interface names can also be used as role names that is >>>>> not what >>>>> my intented meaning was. I was strictly thinking of the interfaces. >> The >>>>> next >>>>> step would be to define operations on these interfaces, which define >> new >>>>> messages that these operations would support. >>>>> >>>>> Does that seem to bring our thoughts and collective understanding >>>>> any >>>>> closer? >>>>> -- >>>>> Regards, >>>>> Farrukh >>>>> >>>>> >>>>> Matthew MacKenzie wrote: >>>>> >>>>>> Farrukh, >>>>>> >>>>>> FederationLeader could refer to a role, rather than anything more >>>>>> concrete, and our conversations could lead toward discussing how, >>>>>> and >>>>>> how dynamically roles are delegated. We have to be careful here, >>>>>> making >>>>>> sure we don't delve too far into the transport layer. Without due >>>>>> care, >>>>>> I can see words like "multicast socket" in our specification! >>>>>> >>>>>> Possible work item: Glossary. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Matt >>>>>> On Friday, May 17, 2002, at 08:37 AM, Farrukh Najmi wrote: >>>>>> >>>>>>> Zach, >>>>>>> >>>>>>> I think that a JXTA project to track development of this part of >>>>>>> the >>>>>>> registry spec is a good idea. I would be interested in >>>>>>> participating >>>>>>> in >>>>>>> such an activity. I agree that we can learn much from JXTA and P2P >> for >>>>>>> this federated registries. Can you recommend some JXTA and other >>>>>>> P2P >>>>>>> material for the team to read? >>>>>>> >>>>>>> BTW, shouldn't Registry Agent Access Layer be called Registry >>>>>>> Access >>>>>>> Agent Layer? >>>>>>> >>>>>>> As I try to relate RAAL my own thinking to the model I proposed, >>>>>>> it >>>>>>> seems that: >>>>>>> >>>>>>> RAAL = FederationLeader + FederationMember >>>>>>> >>>>>>> Does that sound right? If not where do you see differences. Please >>>>>>> note >>>>>>> that in my own thought process I tend to view the world in terms >>>>>>> of >>>>>>> interfaces and interactions between interfaces. >>>>>>> >>>>>>> One thing that I have been unsure of is whether there should be a >>>>>>> designated FederationLeader or not. I guess in a true P2P model >>>>>>> all >>>>>>> members are created equal. But if that were the case then members >>>>>>> would >>>>>>> have to pony up to additional responsibilities that are only >> required >>>>>>> of a member. >>>>>>> >>>>>>> Zachary Alexander wrote: >>>>>>> >>>>>>> Farrukh, Here are my thoughts off the top of my head. I >>>>>>> haven't spent a lot of time drilling down on the implications. I >> have >>>>>>> been pulling together information on specific P2P implementations >> like >>>>>>> jxta. I have also been bouncing around the idea of starting a >>>>>>> jxta >>>>>>> project to track the development of this part of the registry >>>>>>> spec.zack >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] >>>>>>> Sent: Friday, May 17, 2002 9:36 AM >>>>>>> To: regrep-cooperating@lists.oasis-open.org >>>>>>> Subject: Re: [regrep-cooperating] Kickoff of federated registries >> work >>>>>>> item forV3 >>>>>>> >>>>>>> Zach, >>>>>>> >>>>>>> Welcome Zack to the TC and cooperating registries team. Thanks for >>>>>>> getting engaged already. >>>>>>> >>>>>>> Can you clarify the role of the Registry Agent Access layer? Is it >> on >>>>>>> teh client side or registry (server) side. >>>>>>> Could you draw a picture of the prosed architecture and post. Hand >>>>>>> drawn and scanned is fine. >>>>>>> [Zachary Alexander] I see the Registry Agent Access Layer as an >>>>>>> abstraction layer for the registry. This layer would expose >>>>>>> interfaces >>>>>>> and management functions that agents could use to integrate with >>>>>>> the >>>>>>> registry. The way that I am reading the specs on decentralized >>>>>>> applications there are no clients or servers. They use agents. >>>>>>> From >> a >>>>>>> formal standpoint, the web browser is an agent. However , some of >> the >>>>>>> decentralized applications use "rendezvous points" to distribute >>>>>>> agents. I see a division of labor between the Registry Agent and >>>>>>> the >>>>>>> Registry/Repository. The Registry Agent would implement the >> services >>>>>>> that are required for participation in a given internet community >>>>>>> and/or application specific implementation. The Registry would >> handle >>>>>>> the specific needs of the ebXML family of standards. Also, there >> are >>>>>>> really interesting things going on in the distributed agent >> community >>>>>>> that could be of use to the ebXML community. I think that this >>>>>>> would >>>>>>> allow the users to purchase any ebXML compliant Registry and plug >>>>>>> applications or internet community into it. >>>>>>> >>>>>>> I will get a drawing out to the list in the next couple of days. I >> am >>>>>>> doing a computer upgrade and my copy of Visio is not compatible. >>>>>>> So, >> I >>>>>>> am waiting on software. >>>>>>> >>>>>>> I agree with your observation that client to registry interaction >>>>>>> as >>>>>>> essentially client/server today. I am assuming >>>>>>> that there will be no significant change between client/registry >>>>>>> interaction with federated registries. The only change would be >> that: >>>>>>> >>>>>>> -The client would need to specify an optional boolean flad on >> request >>>>>>> to indicated wheher the scope of teh request is federated or >>>>>>> local. >>>>>>> >>>>>>> -the registry would be responsible for returning federated results >> for >>>>>>> a federated scoped query >>>>>>> >>>>>>> The main difference in the federated model as I see is that it >>>>>>> will >>>>>>> introduce peer-to-peer (P2P) interactions between ebXML >>>>>>> registries. >>>>>>> These P2P interactions could be enabled by the registry >>>>>>> implementing >>>>>>> the interfaces I proposed (FederationLeader, FederationMember >>>>>>> etc.). >>>>>>> The implementation of these interfaces would be isolated from the >> core >>>>>>> registry engine in a reasonable implementation. How a registry >>>>>>> implements these interfaces would be up to the registry though. >>>>>>> >>>>>>> Let me know how your mental model differs from mine. >>>>>>> [Zachary Alexander] With the addition of the RAAL (Registry Agent >>>>>>> Access Layer), the current registry/model could be maintained with >>>>>>> only >>>>>>> minor RIM modifications. These modifications could be isolated in >> an >>>>>>> "Experimental section" much like they do with mime-types. The >>>>>>> Agent >>>>>>> would be responsible for the heavy lifting. >>>>>>> >>>>>>> It sounds though that we are getting into more interactive >> discussions >>>>>>> and maybe a meeting would be good sometime soon after we get 2.1 >> specs >>>>>>> out (week of June 10th). Until then lets make some progress over >>>>>>> email. >>>>>>> >>>>>>> PS: I assume that everyone interested should be a member of this >> email >>>>>>> list so no need to CC folks anymore. >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Farrukh >>>>>>> >>>>>>> >>>>>>> >>>>>>> Zachary Alexander wrote: >>>>>>> >>>>>>> Farrukh,I am new to the sub-team and I am trying to get better >>>>>>> understanding of what we are trying to accomplish.Do we want to >>>>>>> change >>>>>>> the Registry spec to accommodate every potential application >>>>>>> architecture? I think that the current ebXML Reg/Rep architecture >>>>>>> is a >>>>>>> client-server architecture. P2P, or what I would call >>>>>>> decentralized >>>>>>> architectures, are very different. IMHO, as we change the ebXML >>>>>>> Reg/Rep spec to accommodate new and potentially conflicting >>>>>>> application >>>>>>> architectures the Reg/Rep spec will become very brittle. I think >> that >>>>>>> this will encourage partial implementations and >>>>>>> incompatibilities.I >>>>>>> was thinking that maybe we could create a "Registry Agent Access >>>>>>> Layer" >>>>>>> that would sit between the ebXML Reg/Rep and the Application >>>>>>> Architecture. I was thinking that if I am a registry owner. I >>>>>>> think >>>>>>> that I would want to be able to plug the ebXML Reg/Rep into a >>>>>>> Gnuella, >>>>>>> Juxtanet, web services, .Net, or whatever else the next big >>>>>>> internet >>>>>>> based application network is without changing my >>>>>>> Reg/RepImplementation. Here's short list of potential agents: >> ebXML >>>>>>> Messaging webservices (i.e., WSDL Related Messaging) .Net >>>>>>> Gnuella Juxtanet AOL URL Mobile Voice Enabled HA >>>>>>> (High Availability) Hashed >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] >>>>>>> Sent: Wednesday, May 08, 2002 1:47 PM >>>>>>> To: regrep-cooperating@lists.oasis-open.org >>>>>>> Cc: Lim Sangwon; zack2@cris.com >>>>>>> Subject: [regrep-cooperating] Kickoff of federated registries work >>>>>>> item >>>>>>> for V3 >>>>>>> >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> The cooperating registry sub-team is about to begin in earnest on >> the >>>>>>> Federated ebXML Registries proposal for V3. The email discussion >>>>>>> on >>>>>>> this should be carried out on the regrep-cooperating@lists.oasis- >>>>>>> open.org mail alias. I am also copying some folks who have >>>>>>> expressed >>>>>>> interest in joining this sub-team and collaborating on this work >> item. >>>>>>> I ask that all those that wish to participate join the >>>>>>> regrep-cooperating@lists.oasis-open.org mailing list using the >>>>>>> following web page: >>>>>>> >>>>>>> http://lists.oasis-open.org/ob/adm.pl >>>>>>> >>>>>>> Next I would like to establish some context for the work item we >>>>>>> are >>>>>>> embarking upon. >>>>>>> >>>>>>> Use Cases Being Addressed By Work Item >>>>>>> >>>>>>> Quite some time ago in this team we defined the following use case >> for >>>>>>> federated registries: >>>>>>> >>>>>>> >>>>>>> Use Case: Peer-to-Peer Federated Registries >>>>>>> [Zachary Alexander] I would change this to "Decentralized >>>>>>> Federated >>>>>>> Registries." Instant Messaging is often considered a P2P >>>>>>> application >>>>>>> but in many cases the architecture is client-server. >>>>>>> >>>>>>> "A group of ebXML Registries wish to project a unified logical >>>>>>> registry >>>>>>> to their clients. To the client it appears as if there is one >> registry >>>>>>> that has the sum total of all the data from all the registries. >>>>>>> This >>>>>>> client experience is the same regardless of which specific >>>>>>> registry >>>>>>> within the federation receives the client request." >>>>>>> >>>>>>> I would like to also add the following use cases as target for >>>>>>> federated registries: >>>>>>> >>>>>>> Use Case: Hierarchically Federated Registries >>>>>>> >>>>>>> "Two registries wish to have a hierarchical parent/child >> relationship >>>>>>> such that the child registry represents a subset of data within >>>>>>> the >>>>>>> larger parent registry. Changes made to the dataset of the child >>>>>>> are >>>>>>> eventually reflected in the parent dataset. Queries made to the >> child >>>>>>> registry return results that reflect the dataset of both the >>>>>>> parent >>>>>>> and >>>>>>> the child registries combined." >>>>>>> [Zachary Alexander] Why would a company do this? How would this >>>>>>> differ >>>>>>> from local registry managing the relationship with an exchange. I >> have >>>>>>> always thought that companies would use internal registries to >> handle >>>>>>> maintenance of content on Industry Registries. Is this what you >>>>>>> are >>>>>>> talking about?Or, does this describe a "virtual hosting >> arrangement?" >>>>>>> Internal registry that is used by employees with an external >>>>>>> virtual >>>>>>> hosted view that is used by customers and/or partners. Use Case: >>>>>>> Caching of Registry Data >>>>>>> "A target registry wishes to cache some or or all of the data of >>>>>>> another another source registry that is willing to share its data. >> The >>>>>>> shared dataset is copied from the source registry to the target >>>>>>> registry and is visible to queries on the target registry even >>>>>>> when >>>>>>> the >>>>>>> source registry is not available." >>>>>>> >>>>>>> Note that this use case is a primitive use case that may be used >>>>>>> to >>>>>>> implement the first two use cases (p2p and hierarchical federated >>>>>>> registries). We may decide that this use case should be removed >>>>>>> as a >>>>>>> separate use case. >>>>>>> [Zachary Alexander] >>>>>>> >>>>>>> Add Use Case: Client-server Federated Registries >>>>>>> >>>>>>> This would allow a ebXML implementation that is built on a >>>>>>> client-server architecture to create a single logical view while >>>>>>> distributing the load between different physical hosts and/or >>>>>>> geographic locations. This could require HA functionality and/or >>>>>>> simple replication. >>>>>>> >>>>>>> Add Use Case: Registry Agent Gateway or Registry Agent Access >>>>>>> Layer >>>>>>> >>>>>>> Create a Registry Agent Gateway that allow an ebXML Registry to >>>>>>> participate in any number of current or future internet >>>>>>> communities/application architectures while isolating the reg/rep >>>>>>> implementation from potential incompatibilities between individual >>>>>>> internet supported communities/application architectures. >>>>>>> >>>>>>> Relevant Links >>>>>>> >>>>>>> The following thread discusses some high level thoughts on the >>>>>>> subject. >>>>>>> >>>>>>> http://lists.ebxml.org/archives/ebxml-dev/200204/msg00127.html >>>>>>> >>>>>>> Next Steps >>>>>>> >>>>>>> I propose the following next steps. We will finalize things as a >> team. >>>>>>> >>>>>>> 1. Begin email discussion on use cases with the proposed 3 use >>>>>>> cases >>>>>>> as starting points >>>>>>> 2. Agree to a time for a kickoff meeting where we indulge in >>>>>>> some >>>>>>> free flowing brainstorming and discussion >>>>>>> 3. Determine team rules, milestones, deliverables and action >> items >>>>>>> 4. Meet periodically over phone to sync on deliverables >>>>>>> >>>>>>> Proposed Meeting Time >>>>>>> >>>>>>> There is no proposed meeting time until we know who is part of the >>>>>>> team >>>>>>> and where are they located and what are their preferences. Please >> send >>>>>>> me this information privately if you wish to be part of the team. >>>>>>> >>>>>>> Proposed Team Rules >>>>>>> >>>>>>> Here are some suggestions: >>>>>>> >>>>>>> • To be a member of the team you must be willing to >>>>>>> contribute. >>>>>>> Contributions may involve one or more of the following: attending >> team >>>>>>> meetings, authoring spec content, implementing proof-of-concepts >>>>>>> (POC), >>>>>>> taking action items, taking meeting notes, tracking issues etc. >>>>>>> • No duplication of effort. Every one executes on an agreed >>>>>>> plan >>>>>>> and >>>>>>> action items. >>>>>>> >>>>>>> Proposed Milestones / Deliverables >>>>>>> >>>>>>> • Team formation - by COB (Close of business, 6pm US Eastern) >> Wed >>>>>>> May 15 >>>>>>> • Kickoff meeting - by COB May 24th >>>>>>> • Agreement on Use Cases - by COB May 24 >>>>>>> • First draft of written proposal by COB June 7 >>>>>>> • POC implementation begins by COB June 7th (Note that it is >>>>>>> the >>>>>>> intent of this work item to do a parallel implementation so that >>>>>>> the >>>>>>> specs are ground firmly in reality and practical experience.) >>>>>>> • POC implementation completed by COB July 26th >>>>>>> • Proposed Final draft to TC by COB August 9th >>>>>>> • Final draft to Editors by COB Aug 30th >>>>>>> >>>>>>> Immediate Action Items >>>>>>> >>>>>>> • Confirm intent to be a team member privately to me by Monday >> 6pm >>>>>>> US Eastern. Please indicate preferences for meeting day/time. >>>>>>> (All >>>>>>> interested) >>>>>>> • Join the regrep-cooperating@lists.oasis-open.org mailing >>>>>>> list >>>>>>> ASAP >>>>>>> (All) >>>>>>> • Share on team alias, any proposals that you may have in the >>>>>>> works >>>>>>> related to federated registries. This is to avoid duplication of >>>>>>> effort. (All) >>>>>>> • Discuss on team alias, the proposed use cases via email, as >> well >>>>>>> as sends any other comments on this email (All) >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Farrukh >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Farrukh >>>>>>> >>>>>>> >>>>>>> -- Matthew MacKenzie XML Global R&D PGP Key available upon request. >>>>>> >>>>>> ---------------------------------------------------------------- >>>>>> 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] | [Elist Home]
Powered by eList eXpress LLC