[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep-cooperating] Federation Protocol Profile
Matt, Good point about the IPR issue (to be logged by issue keeper). We should all know what the status is before we proceed down that CPP/A path. I will try and get some clarity on this. Matthew MacKenzie wrote: > 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> -- Regards, Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC