[regrep-cooperating] Federation Protocol Profile

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

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>