Re: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI nfo

[Arvola Chan <arvola@tibco.com>]

Chris:

Manifest is at the same level as MessageHeader. Manifest has
a sub-element

<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded" />

Why can't we have a similar sub-element under MessageHeader?

Thanks,
-Arvola

-----Original Message-----
From: christopher ferris <chris.ferris@east.sun.com>
To: ebXML Msg <ebxml-msg@lists.oasis-open.org>;
ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Monday, August 27, 2001 3:20 PM
Subject: Re: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI
nfo


Arvola,

Extending MessageHeader in this manner won't provide
for the extension to be accorded the semantics of
SOAP:mustUnderstand=1 which is reserved for direct
children of the SOAP:Header element.

Cheers,

Chris
Arvola Chan wrote:
>
> Marty and David:
>
> As I have indicated in my recent messages to Hima, there are still
> issues with how the Service and Action elements ought to be
> populated with values obtained from the business process specification.
>
> http://lists.oasis-open.org/archives/ebxml-cppa/200108/msg00200.html
> http://lists.oasis-open.org/archives/ebxml-cppa/200108/msg00206.html
>
> I think we should make sure that business processes specified using
> BPSS can have their messages easily transportable by the Messaging
> Service.
>
> To address the rarer scenarios, I am in favor of allowing one or more
> namespace qualified extension elements at the same level as
>
> >- From Party
> >- To Party
> >- Service
> >- Action
> >- Conversation Id
> >- RefToMessageId
> >- CPAId
>
> Currently, it is possible for anyone to directly extend the SOAP header,
> but I think adding extensibility to the eb:MessageHeader is preferrable.
>
> Regards,
> -Arvola
>
> -----Original Message-----
> From: Martin W Sachs <mwsachs@us.ibm.com>
> To: Burdett, David <david.burdett@commerceone.com>
> Cc: 'Arvola Chan' <arvola@tibco.com>; David Fischer
> <david@drummondgroup.com>; ebXML Msg <ebxml-msg@lists.oasis-open.org>;
> ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
> Date: Monday, August 27, 2001 11:23 AM
> Subject: RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceI
> nfo
>
> >
> >David,
> >
> >I think that RosettaNet is hardly a rare case but I will wait for Arvola
to
> >answer this one since he brought up the inadequacy of service and action.
> >
> >Regards,
> >Marty
> >
>
>***************************************************************************
> **********
> >
> >Martin W. Sachs
> >IBM T. J. Watson Research Center
> >P. O. B. 704
> >Yorktown Hts, NY 10598
> >914-784-7287;  IBM tie line 863-7287
> >Notes address:  Martin W Sachs/Watson/IBM
> >Internet address:  mwsachs @ us.ibm.com
>
>***************************************************************************
> **********
> >
> >
> >
> >"Burdett, David" <david.burdett@commerceone.com> on 08/27/2001 01:08:12
PM
> >
> >To:   Martin W Sachs/Watson/IBM@IBMUS
> >cc:   "'Arvola Chan'" <arvola@tibco.com>, David Fischer
> >      <david@drummondgroup.com>, ebXML Msg
> >      <ebxml-msg@lists.oasis-open.org>, ebxml-cppa@lists.oasis-open.org
> >Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceI
> >      nfo
> >
> >
> >
> >Hi Marty ...
> >
> >>>>considering that there are still open questions on service and action,
> >whether two levels of routing are sufficient<<<
> >
> >Our experience shows that you can **never** cover all cases. There is
> >always
> >some odd business reason that requires you, in relatively rare
> >circumstances, to look into the payload to determine where to send a
> >message. This makes me think that we should not try to cover every
possible
> >case and, instead use an approach that meets the need of most situations.
> >In
> >implementation terms what this means is that these "relatively rare"
> >messages are first routed to an custom application that can look into the
> >payload and work out what to do. The custom application then forwards the
> >message to the required application.
> >
> >However I do think that with good business process design you can get
> >around
> >these propblems. So do you think that the current list of message header
> >elements are sufficient:
> >- From Party
> >- To Party
> >- Service
> >- Action
> >- Conversation Id
> >- RefToMessageId
> >- CPAId
> >
> >...
> >
> >I also completely agree with you about getting version 1.1 out as soon as
> >we
> >can. The timetable we agreed at our meeting in Dallas was along the
> >following lines:
> >1. Get comments by August 17th
> >2. Prepare list of changes and review in F2F - by end September early
> >October
> >3. Publish draft of version 1.1 by early November
> >4. Review spec following normal OASIS guidelines
> >
> >David
> >
> >
> >-----Original Message-----
> >From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> >Sent: Sunday, August 26, 2001 2:52 PM
> >To: Burdett, David
> >Cc: 'Arvola Chan'; David Fischer; ebXML Msg;
> >ebxml-cppa@lists.oasis-open.org
> >Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> >QualityOfServiceI nfo
> >
> >
> >
> >David,
> >
> >I was referring specifically to v 1.1.  In the long run, you are probably
> >right but considering that there are still open questions on service and
> >action, whether two levels of routing are sufficient, and also whether
> >RefToMessageId should be specifically defined as identifying the message
to
> >which a response message is responding, I have to view that as post Ver.
> >1.1.  Meanwhile, it works today if we admit that each delivery channel
has
> >a unique endpoint address although, as you point out, it can get fairly
> >cumbersome.
> >
> >Editorial note:  It is becoming increasingly clear to me that the CPPA
and
> >MSG teams should focus on completing Version 1.1 as quickly as possible
and
> >getting it approved as an OASIS standard.  For various political and
> >marketing reasons, "OASIS Standard" will sound more compelling that
"ebXML
> >Specification". "Completing it quickly" means triaging and moving
> >everything that is more than a clarification or agreed bug fix out beyond
V
> >1.1.
> >
> >Regards,
> >Marty
> >
>
>***************************************************************************
> *
> >
> >*********
> >
> >Martin W. Sachs
> >IBM T. J. Watson Research Center
> >P. O. B. 704
> >Yorktown Hts, NY 10598
> >914-784-7287;  IBM tie line 863-7287
> >Notes address:  Martin W Sachs/Watson/IBM
> >Internet address:  mwsachs @ us.ibm.com
>
>***************************************************************************
> *
> >
> >*********
> >
> >
> >
> >"Burdett, David" <david.burdett@commerceone.com> on 08/24/2001 08:18:28
PM
> >
> >To:   "'Arvola Chan'" <arvola@tibco.com>, David Fischer
> >      <david@drummondgroup.com>, Martin W Sachs/Watson/IBM@IBMUS
> >cc:   ebXML Msg <ebxml-msg@lists.oasis-open.org>
> >Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
QualityOfServiceI
> >      nfo
> >
> >
> >
> >Folks
> >
> >I strongly agree with Arvola.
> >
> >It is unrealistic require in the ebXML Messaging spec that each delivery
> >channel has a different endpoint. You should be able to use Service and
> >Action to identify which application should receive a message instead and
> >then route, if you want to, all messages to the same endpoint.
> >
> >Consider, for example, a payment service operated by a bank. This could
> >potentially be included in many different collaborations and CPAs for the
> >eCommerce sites that use the bank's service to do a credit card payment.
> >
> >I would suggest that what the bank wants to do is publish a single URL to
> >which all (or many) messages from different businesses are sent rather
than
> >vary it for each business.
> >
> >... or am I missing something ...
> >
> >David
> >
> >-----Original Message-----
> >From: Arvola Chan [mailto:arvola@tibco.com]
> >Sent: Tuesday, August 21, 2001 8:29 AM
> >To: David Fischer; Martin W Sachs
> >Cc: ebXML Msg
> >Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> >QualityOfServiceInfo
> >
> >
> >David:
> >
> >Marty is saying that we need to at least require delivery channels to
> >have unique endpoint addresses for 1.1.
> >
> >Using the ServiceBinding override mechanism, it is possible to
> >specify a delivery channel with syncReplyMode for a particular
> >action (for the receiver).
> >
> >From the CPA, both the sender and the receiver should know that the
> >action in question is associated with a unique delivery channel. When a
> >message arrives on the associated endpoint address, the receiver
> >should have no difficulty to know that it has to respond synchronously
> >because the delivery channel is a synchronous one.
> >
> >-Arvola
> >
> >-----Original Message-----
> >From: David Fischer <david@drummondgroup.com>
> >To: Martin W Sachs <mwsachs@us.ibm.com>
> >Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
> >Date: Tuesday, August 21, 2001 8:00 AM
> >Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> >QualityOfServiceInfo
> >
> >
> >This is exactly the problem I see.  How do I send to the same address but
> >slightly vary the parameters (change SyncReply from True to False)?
Chris
> >suggested (I think) that all that was necessary was to define another
> >DeliveryChannel.  I don't understand how this solves the problem since I
> >can't
> >figure out how to tell the receiver which DeliveryChannel to use -- maybe
I
> >can't by design which means this solution won't work.  This is too
tightly
> >coupled!
> >
> >Am I missing the mark?  If not, then I need to go back to my original
> >premise
> >that SyncReply needs to be in MessageHeader.
> >
> >Regards,
> >
> >David Fischer
> >Drummond Group.
> >
> >-----Original Message-----
> >From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> >Sent: Monday, August 20, 2001 10:20 PM
> >To: Arvola Chan
> >Cc: David Fischer; Christopher Ferris (E-mail); ebXML Messaging
> >(E-mail); ebxml-cppa@lists.oasis-open.org
> >Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> >QualityOfServiceInfo
> >
> >
> >
> >Arvola,
> >
> >It's late at night and I have just gone through 140 emails accumulated
> >Friday and today so maybe I am getting a bit dull.
> >
> >Each party knows about its delivery channels and the other party's
delivery
> >channels and which one goes with each business transaction.  This is the
> >information that is in the CPA and has to be installed in each party's
> >system.
> >
> >The missing element in your posting is the endpoint address, defined for
> >each delivery channel.  As long as each delivery channel has a unique
> >endpoint address, the From MSH should have no ambiguity in where to send
> >each message and the To MSH has no ambiguity in which delivery channel to
> >use for a received message.  Service and Action should be needed only by
> >the To Party's MSH and only for routing to the application entry point.
> >There may be a problem if one wants to define two delivery channels with
> >the same endpoint address but slight variations in some parameters.  I
> >believe that we have assumed that each delivery channel has a unique
> >endpoint address but I suspect that we don't say so.  Allowing two
> >different delivery channels to share an endpoint address would certainly
> >require an additional piece of information that the To MSH would need to
> >use to identify the correct receive channel for an incoming message.
> >
> >I suggest that V1.1 state that every delivery channel SHALL have a unique
> >endpoint address (if V1.0 doesn't say so).  For V2.0, we could consider
> >permitting different delivery channls to share the same endpoint address
> >and adding whatever disambiguator is required to make this work.
> >
> >Regards,
> >Marty
> >
> >Regards,
> >Marty
> >
>
>***************************************************************************
> *
> >
> >
> >****
> >*****
> >
> >Martin W. Sachs
> >IBM T. J. Watson Research Center
> >P. O. B. 704
> >Yorktown Hts, NY 10598
> >914-784-7287;  IBM tie line 863-7287
> >Notes address:  Martin W Sachs/Watson/IBM
> >Internet address:  mwsachs @ us.ibm.com
>
>***************************************************************************
> *
> >
> >
> >****
> >*****
> >
> >
> >
> >Arvola Chan <arvola@tibco.com> on 08/20/2001 09:43:52 PM
> >
> >To:   David Fischer <david@drummondgroup.com>, "Christopher Ferris
> >      (E-mail)" <chris.ferris@east.sun.com>
> >cc:   "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>,
> >      ebxml-cppa@lists.oasis-open.org
> >Subject:  Re: T2 SyncReply and ReliableMessagingMethod in
> >      QualityOfServiceInfo
> >
> >
> >
> >David and Chris:
> >
> >I have a similar issue. It is not clear to me that a sender MSH
> >can uniquely determine a delivery channel to be used to send to
> >a receiver without knowing the collaboration role played by the
> >receiver.
> >
> >The structure of the CPP/A elements is such that a Party
> >may play multiple collaboration roles. For each such role,
> >there can be one or more prioritized service bindings. Each
> >service binding has a service element that essentially identifies
> >the service provided by the party in question. Each service
> >binding specifies a default delivery channel, along with zero
> >or more override elements. Each override element pertains
> >to a particular action and specifies the delivery channel for
> >that action.
> >
> >If the sender knows the role played by the receiver, then it
> >is straightforward to determine the delivery channel that should
> >be used in order to send the message to the receiver. However,
> >there is no role element in the message header. If the Message
> >Service Interface is defined in such a way that the burden of
> >determining the delivery channel falls on the MSH, then I am
> >not sure if the MSH has sufficient information to determine
> >the delivery channel. The problem I see is that the service
> >name associated with a service binding is not necessarily
> >unique. Is it possible to have multiple roles played by the
> >same receiver with service bindings that share the same
> >service name? If so, it is not clear to me which corresponding
> >delivery channel should be used. For this discussion, let's assume
> >that none of the service bindings in the CPA have override elements.
> >Thus, it is not possible to use the Action element in the message
> >header to determine the delivery channel.
> >
> >Regards,
> >-Arvola
> >
> >-----Original Message-----
> >From: David Fischer <david@drummondgroup.com>
> >To: Christopher Ferris (E-mail) <chris.ferris@east.sun.com>
> >Cc: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org>
> >Date: Monday, August 20, 2001 5:33 PM
> >Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> >QualityOfServiceInfo
> >
> >
> >Maybe I acceded to quickly?  I am trying to understand how to use another
> >delivery channel to support SyncReply.  I see CPAid in the MessageHeader
so
> >the
> >receiving end knows which CPA to use.  I guess the DeliveryChannel is
> >chosen
> >based upon which transport is involved.
> >
> >What if there are two DeliveryChannels with the same transport.  One HTTP
> >w/
> >SyncReply=True and one HTTP w/ SyncReply=False, how does the receiver
know
> >which
> >one to use?  The CPAid would be the same.  Do we need to append the
> >DeliveryChannel ID on the end?
> >
> ><eb:CPAid>CompanyA-003</eb:CPAid>
> >
> >Where CPAid is "CompanyA" and the DeliveryChannel ID is "003"?  I'm not
> >sure
> >how
> >the sender tells the receiver which DeliveryChannel to use.  Please
forgive
> >my
> >ignorance but, how does this work?
> >
> >David Fischer
> >Drummond Group.
> >
> >-----Original Message-----
> >From: David Fischer [mailto:david@drummondgroup.com]
> >Sent: Friday, August 10, 2001 10:37 AM
> >To: Arvola Chan
> >Cc: ebXML Messaging (E-mail)
> >Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> >QualityOfServiceInfo
> >
> >
> >Arvola, I agree with you but I don't think this is a significant enough
> >Requirement to fight for.  I will accede to the majority as long as it
> >seems
> >like a workable solution.
> >
> >My personal opinion is that everything in the Via (CPA message related
> >parameters) should also be represented in MessageHeader -- again I don't
> >feel
> >strongly enough about this to fight for it very much.
> >
> >Regards,
> >
> >David Fischer
> >Drummond Group.
> >
> >-----Original Message-----
> >From: christopher ferris [mailto:chris.ferris@east.sun.com]
> >Sent: Friday, August 10, 2001 6:09 AM
> >To: Arvola Chan
> >Cc: David Fischer; Burdett David; ebXML Messaging (E-mail);
> >ebxml-cppa@lists.oasis-open.org
> >Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> >QualityOfServiceInfo
> >
> >
> >Arvola,
> >
> >It was not the intent to require use of the syncReplyMode
> >attribute (and hence the Via). The two parties exchanging
> >messages point-to-point are assumed to "know" by virtue of
> >their CPA (or the virtual equivalent of one) what their
> >syncReplyMode is. The Via element needs this because the
> >intermediaries don't have access to this information.
> >
> >Cheers,
> >
> >Chris
> >
> >Arvola Chan wrote:
> >>
> >> David:
> >>
> >> I don't think using a second DeliveryChannel will work. The following
is
> >an
> >> excerpt from the CPP/A spec:
> >>
> >> The ebXML Message Service's syncReply attribute is set to a value of
> >"true"
> >> whenever the 1190
> >> syncReplyMode attribute has a value other than "none". 1191
> >>
> >> Even if you have a channel that calls for the use of synchronous reply
> >mode,
> >> the syncReply attribute still has to be set. In other words, it is
still
> >> necessary to use the Via element if the syncReply attribute is present
> >only
> >> there, but this constradicts the assumption that the Via element is
only
> >> used when intermediaries are involved.
> >>
> >> -Arvola
> >>
> >> ----- Original Message -----
> >> From: "David Fischer" <david@drummondgroup.com>
> >> To: "Arvola Chan" <arvola@tibco.com>; "Burdett David"
> >> <david.burdett@commerceone.com>
> >> Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
> >> Sent: Thursday, August 09, 2001 7:45 PM
> >> Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> >> QualityOfServiceInfo
> >>
> >> > This was my original proposal, syncReply in both.  However, I was
told
> >> this
> >> > could be accomplished using a second DeliveryChannel.  While this is
> >not
> >> my
> >> > first preference, it would work...  <shrug>
> >> >
> >> > David Fischer
> >> > Drummond Group
> >> >
> >> > -----Original Message-----
> >> > From: Arvola Chan [mailto:arvola@tibco.com]
> >> > Sent: Thursday, August 09, 2001 12:24 PM
> >> > To: Burdett David; David Fischer (E-mail)
> >> > Cc: ebXML Messaging (E-mail)
> >> > Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> >> > QualityOfServiceInfo
> >> >
> >> >
> >> > David:
> >> >
> >> > I was mostly concerned with how to obtain synchronous replies in the
> >> single
> >> > hop case, assuming the Via element is to be used exclusively for
> >multi-hop
> >> > scenarios. I didn't realize there is a need to have syncReply vary
hop
> >by
> >> > hop.
> >> >
> >> > I think it is reasonable to have syncReply both in the QOS and in the
> >Via
> >> > elements, and to say that the information in the Via element
overrides
> >the
> >> > information in the QOS element. I don't have any particular
preference
> >> > between the names Via versus RoutingHeader.
> >> >
> >> > Thanks,
> >> > -Arvola
> >> >
> >> > -----Original Message-----
> >> > From: Burdett, David <david.burdett@commerceone.com>
> >> > To: David Fischer (E-mail) <david@drummondgroup.com>; 'Arvola Chan'
> >> > <arvola@tibco.com>
> >> > Cc: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org>
> >> > Date: Thursday, August 09, 2001 9:57 AM
> >> > Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> >> > QualityOfServiceInfo
> >> >
> >> >
> >> > >Arvola
> >> > >
> >> > >I disagree. You need syncReply in the Via. The attached PDF file
> >titled
> >> > "Why
> >> > >you need syncReply in the Via" contains a diagram which illustrates
> >the
> >> use
> >> > >case. Where the first hop is synchronous and the second not.
> >> > >
> >> > >If we want Via to be used only when intermediaries are being used
then
> >> you
> >> > >would need ackRequested held elsewhere, e.g. in the Quality of
> >Service.
> >> > >However since syncReply can vary from hop to hop (see previous
> >example),
> >> > you
> >> > >would then need to also have it in the Via and a rule that the Via
> >> > >over-rides the QoS.
> >> > >
> >> > >There is also the issue that the sender of a message may not know
that
> >it
> >> > is
> >> > >multiple hop as the PDF file titled "Using ebXML RM behind the
> >firewall"
> >> > >illustrates. In this case external communications are done
> >synchronously,
> >> > >but the messaging to an application within the company is done
> >> > >asynchronously.
> >> > >
> >> > >I think we need to keep ackRequested and syncReply in the Via, but
> >rename
> >> > it
> >> > >... to "Routing Header" perhaps, although I have no strong
preference
> >...
> >> > ;)
> >> > >
> >> > >I'd appreciate your thoughts on these use cases.
> >> > >
> >> > >David
> >> > >PS Slides very similar to these two were posted ages ago and
discussed
> >in
> >> > >Tokyo last November I think.
> >> > >
> >> > >
> >> > >-----Original Message-----
> >> > >From: Arvola Chan [mailto:arvola@tibco.com]
> >> > >Sent: Wednesday, August 08, 2001 6:59 PM
> >> > >To: David Fischer; ebXML Msg
> >> > >Subject: Re: T2 SyncReply and ReliableMessagingMethod in
> >> > >QualityOfServiceInfo
> >> > >
> >> > >
> >> > >David:
> >> > >
> >> > >Sorry for the delayed response. I agree with you that the Via
element
> >> > should
> >> > >be used exclusively for those cases where intermediaries are
involved.
> >> > >Therefore, it makes sense to move the syncReply and ackRequested
> >> attributes
> >> > >to be under the QualityOfServiceInfo element.
> >> > >
> >> > >Since there already is a deliverySemantics attribute under the
> >> > >QualityOfServiceInfo element, and the reliableMessagingMethod
> >attribute
> >> can
> >> > >vary from one hop to another, I think reliableMessagingMethod should
> >stay
> >> > in
> >> > >the Via element.
> >> > >
> >> > >Regards,
> >> > >-Arvola
> >> > >
> >> > >-----Original Message-----
> >> > >From: David Fischer <david@drummondgroup.com>
> >> > >To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
> >> > >Date: Monday, August 06, 2001 8:51 PM
> >> > >Subject: T2 SyncReply and ReliableMessagingMethod in
> >QualityOfServiceInfo
> >> > >
> >> > >
> >> > >There should be nothing in the Via which is not also in other
headers.
> >> Via
> >> > >should only be used for multi-hop intermediaries.  In the case of
> >> > SyncReply,
> >> > >there is no single-hop way of requesting SyncReply=true.
> >> > >
> >> > >Attributes SyncReply and ReliableMessagingMethod should also be in
> >> > >QualityOfServiceInfo.  They should retain their current defaults.
> >> > >
> >> > >Regards,
> >> > >
> >> > >David Fischer
> >> > >Drummond Group.
> >> > >
> >> > >
> >> > >------------------------------------------------------------------
> >> > >To unsubscribe from this elist send a message with the single word
> >> > >"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> >> > >
> >> > >
> >> > >------------------------------------------------------------------
> >> > >To unsubscribe from this elist send a message with the single word
> >> > >"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> >> > >
> >> > >
> >> >
> >> >
> >>
> >> ------------------------------------------------------------------
> >> To unsubscribe from this elist send a message with the single word
> >> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> >
> >
> >------------------------------------------------------------------
> >To unsubscribe from this elist send a message with the single word
> >"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
> >
> >
> >----------------------------------------------------------------
> >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>
> >
> >
> >
> >----------------------------------------------------------------
> >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>