OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues


David,

Please see below.

Cheers,

Chris

David Fischer wrote:
> 
> Chris,
> 
> Wow, what a proposal!  I *think* your way would work but it is such a
> substantial change to the way the spec reads now that I would vote NO just on
> those grounds.  Version 1.1 is supposed to be only bug fixes.  Your proposal
> also does not address (intentionally) what I perceive as a requirement --
> end-to-end MSH level receipts.  We don't want to have to go all the way to the
> application to determine whether or not to retry.  Each developer would have to
> write this code into EVERY APPLICATION.  No, we can't do things that way.  This
> is Transport Layer functionality.

Let us not confuse "application layer" with application here. By "application
layer" I mean a level of software that is above the MSH in the stack. If you
have an eBusiness Server, the MSH is only a component of that. The determination
can be left to that level since we are concerned not with defining a specification
for an implementation of an eBusiness Server, but of a wire protocol and required
behavior of an abstract MSH. 

> 
> If you don't want to call Delivery Receipts a part of Reliable Messaging, I
> don't really care.  I don't want to quibble over semantics.  Whatever the
> process ends up being called, MSH level Delivery Receipts are essential and the
> ability to retry on lack of a Delivery Receipt is just as important.  This was
> all in the specification prior to multi-hop and it needs to stay there.  DB's
> proposals do just that and I support them.

As I have said before, we don't need to support end-to-end retries if we
have (as I know we all understood) a consistent application of RM semantics
at all MSH nodes involved in a message exchange.

We never discussed end-to-end retries above and beyond p2p retries in TR&P
until you raised this issue post 1.0 publication. If anything is v2.0,
then I would think that end-to-end retries over and above p2p RM is.

> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]On Behalf Of
> christopher ferris
> Sent: Friday, September 07, 2001 1:34 PM
> To: ebXML Messaging (E-mail)
> Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues
> 
> My turn;-)
> 
> Please see my comments below.
> 
> Cheers,
> 
> Chris
> 
> "Burdett, David" wrote:
> >
> > Arvola
> >
> > See comments in line.
> >
> > David
> >
> > -----Original Message-----
> > From: Arvola Chan [mailto:arvola@tibco.com]
> > Sent: Thursday, September 06, 2001 4:47 PM
> > To: ebXML Messaging (E-mail)
> > Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues
> >
> > David and David:
> >
> > I don't have any major objection to the proposed changes.
> > My comments are in tandem with David Fischer's bracketed
> > by <ac> and </ac>.
> >
> > Regards,
> > -Arvola
> >
> > -----Original Message-----
> > From: David Fischer <david@drummondgroup.com>
> > To: Burdett, David <david.burdett@commerceone.com>; ebXML Messaging (E-mail)
> > <ebxml-msg@lists.oasis-open.org>
> > Date: Thursday, September 06, 2001 3:19 PM
> > Subject: RE: T2 PLEAE READ - Suggested solution to RM Issues
> >
> > David,
> >
> > Looks pretty good.
> > <df>Comments inline</df>
> >
> > Regards,
> >
> > David.
> >
> > -----Original Message-----
> > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > Sent: Thursday, September 06, 2001 1:44 PM
> > To: ebXML Messaging (E-mail)
> > Subject: T2 PLEAE READ - Suggested solution to RM Issues
> >
> > Folks
> >
> > If you do not respond to this email then, as chair of the T2 effort, I AM
> > GOING TO ASSUME YOUR SUPPORT. So please read at least the first part of this
> > email which explains why I am doing this ...
> >
> > There has been a LOT of discussion about Reliable Messaging on the list. I
> > also sense that different people's views are gradually aligning. However to
> > move forward we HAVE to come up with constructive suggestions. I first did
> > this a nearly a month ago see ...
> >
> > http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00125.html
> >
> > Although there were a lot of replies to this email few of them were about
> > the actual suggestions I made. Those that were received (Arvola Chan & David
> > Fischer) were generally in agreement although both suggested worthwhile
> > improvements. So in order to focus on the solution I have restated the
> > approach in my earlier email below with a few tweaks to reflect more recent
> > discussions.
> >
> > What I think will be really constructive is if we use this suggested
> > solution as the basis for discussion so that we can refine it and hopefully
> > finalize it in the F2F on October 3-5. Once we get agreement we can then
> > start making changes.
> >
> > Furthermore, AS CHAIR OF THE T2 EFFORT I AM GOING TO ASSUME THAT NO COMMENT
> > MEANS ACCEPTANCE. I don't like doing this but unless we start talking about
> > solutions rather than problems we will not make progress.
> >
> > Does this makes sense?
> >
> > Finally, I've missed some of the detail of the discussions in order to make
> > the suggested solution (fairly) brief. This does not mean they are not
> > included ... they definitely will need to be ... and if they are important,
> > I am sure you will make your views known ;)
> >
> > Best wishes to everyone.
> >
> > David
> > SUGGESTED CHANGES TO SOLVE RM ISSUES
> >
> > Change 1
> > --------
> > Summary: Rename the Via element as "Next Actor Data" or similar.
> >
> > Rationale: There can always be "intermediaries" in a message transfer even
> > if you are going point-to-point. For example consider the two example
> > message flows that I recently posted that cover the following use cases:
> > 1. A genuine intermediary who is a third party that is running a MSH and
> > forwards messages to the final destination.
> > 2. A Party which has a MSH that acts as a "mailroom" that forwards the
> > message internally using ebXML RM to another MSH that then forwards it to
> > the application. The "mailroom" MSH ia an intermediary. Chris Ferris
> > provided an example of this use case at
> > http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00412.html
> >
> > I think we need to support both use cases. By renaming the Via element as
> > "Next Actor Data". We are simply saying that the data contained within the
> > element is for the Next Actor **only** and does not need to be forwarded.
> > The Next Actor recreates the data as they need to if they are forwarding the
> > message. If we think of the data in the Via as being for the "Next Actor"
> > then we are also more closely aligned with SOAP. It also removes the problem
> > of treating intermediaries as "something special" and allows an internal MSH
> > to forward the message to another MSH without the original sender needing to
> > know and without having to re-create the complete message.
> >
> > <df>I agree with all your rationale.  My only question is backward
> > compatibility
> > issues with 1.0 implementations due to the name changes.</df>
> 
> <cf>
> I agree that the name change seems arbitrary and should only be taken
> after careful consideration of any backwards-compatibility issues.
> </cf>
> 
> >
> > <ac>
> > I am ambivalent about the name change. Clarification of the intent of the
> > element and its usage rule is sufficient for me.
> > </ac>
> > <db>We might need to vote on this.</db>
> 
> <cf>
> My take is that lumping *all* of the stuff designated for the "next" actor
> would be a mistake. We should be leveraging SOAP as it is intended. IMO, a
> SOAP "block" or header should have a specific purpose. More comments on
> this below.
> </cf>
> 
> >
> > Change 2
> > --------
> > Summary: Data in the Next Actor Data (Via) element is for the Next Actor
> > only
> >
> > Rationale: What Change 1 means is that we must carefully review the existing
> > elements in the header and check to see whether they are needed by the
> > ultimate destination/endpoint or the next actor. I think that this will
> > require the following changes:
> > 1. CPAId. The CPAId in the Message Header identifies parameters that apply
> > "end-to-end", e.g. business process level stuff, whereas the CPAId in the
> > NAD/Via element applies to the transport over a single hop, e.g. transport
> > level stuff. I realise this will require changes to the CPP/A ... and
> > probably more discussion.
> >
> > <df>Agreed.  This may not require any CPA change at all since, as Marty put
> > it,
> > multi-hop is just a set of binary collaborations.  There is a CPA with the
> > end
> > and a CPA with the next hop.  This is perfect.  What is the value if there
> > is no
> > IM?  Needs to be optional or allowed to be empty.</df>
> >
> > <ac>
> > I agree with David Fischer.
> > </ac>
> 
> <cf>
> As I believe David B has pointed out, the CPAId in the Via element is
> currently optional in the v1.0 spec.
> </cf>
> 
> >
> > 2. Acknowledgment Element. This should be part of the NAD/Via element as
> > acknowledgments are between two MSHs and are not propogated to the original
> > sending party.
> >
> > <df>No, if we move Acknowledgement to Via then we remove it from the
> > Signature.
> > This is OK if we don't want signed Acknowledgements.
> >
> > <ac>
> > I suppose it is possible that the CPA between two intermediate MSH
> > calls for non repudiation of receipt in which case the Acknowledgement
> > would have to be signed. I vote for keeping the Acknowledgement
> > element outside of the Via element.
> > </ac>
> > <db>I agree with this also and have withdrawn this suggested change.</db>
> 
> <cf>
> Agree that Acknowledgment, which is already targetted at the "next" actor
> should remain as a separate SOAP header block as per the v1.0 spec.
> </cf>
> 
> >
> > If we are going to make this massive a change, then let's go all the way and
> > move TraceHeaderList to Via and simplify the ds:Signature Transform.
> > TraceHeaderList must be modified by each hop and then passed to the next.
> > TraceHeaderList is intended for the next hop so it also should be part of
> > Via.
> >
> > <ac>
> > I agree that it makes logical sense to move the TraceHeaderList
> > under the Via/NAD element.
> > </ac>
> > <db>I've a change of view here in that we should not move it unless there is
> > a real reason. We just need to make it clear what the "next" and "to" actors
> > need to do with each SOAP extension</db>
> > </df>
> 
> <cf>
> The TraceHeader list is already targetted at the 'next' actor. I see no
> reason whatsoever to relocate it.
> </cf>
> 
> >
> > Change 3
> > --------
> > Summary: Make Next Actor Data (was Via) a required element.
> >
> > Rationale: There are two reasons for this:
> > 1. The current Via element contains data that is REQUIRED for
> > point-to-point, e.g. ReliableMessagingMethod.
> 
> <cf>
> If you have a CPA, whether real or imagined, and no intermediary then
> ReliableMessagingMethod is not needed in the message itself. The two nodes
> already have an understanding as to how they are effecting RM as per their
> agreement. Thus, it is not REQUIRED for point-to-point RM at all.
> </cf>
> 
> > 2. There are two levels of reliability, that need to be covered:
> > point-to-point (P2P) as well as end-to-end (E2E).
> 
> <cf>
> The fact that the parties agree to exchange receipts is orthogonal
> to RM. The fact that the RM protocol that is defined by the spec
> uses Acknowledgments is mere coincidence. We could have employed
> other mechanisms to acheive reliability. If it is desired that
> there be a formal expression of the equivalent of "I expect an
> acknowledgement" in the SOAP envelope, targetted at the "next"
> actor with a mustUnderstand=1, I suppose I have no problem with
> that. I would prefer that it be a standalone SOAP header and not
> merely lumped in with a bunch of other stuff.
> </cf>
> 
> >
> > Currently Via is optional. If we are doing point-to-point, then you would
> > have to have ReliableMessagingMethod duplicated at the header level in order
> > to solve the problem. This does not make sense. Making NAD required solves
> > this problem.
> 
> <cf>
> See above, I disagree with the assertion that ReliableMessagingMethod
> is required in the MessageHeader.
> </cf>
> 
> >
> > The layering problem of P2P vs E2E is similar to the problem that TCP/IP
> > solves as was clearly stated by Dan Weinreb at
> > http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00225.html. Marty
> > Sachs, David Fischer and others have also repeatedly said that unless you
> > have end-to-end acknowledgement then there is no certainty. I think we need
> > to recognize that there can always be two levels and therefore need to
> > recognize both these levels in the header.
> >
> > Now TCP/IP does this as two SEPARATE layers. The current spec puts both
> > layers in one spec with one header. I don't think we NEED to radically
> > change the spec in this area but would like peoples views.
> >
> > <df>Agreed.  What is the value of Via CPAId if there is no IM?</df>
> >
> > <ac>
> > The CPAId under the Via element is optional according to the XSD.
> > If the QOS is BestEffort and no intermediary MSH is involved, there
> > is no need for the Via/NAD element. I think it can remain optional as
> > long as we can clearly articulate the circumstances under which it must
> > be present.
> > </ac>
> > <db>Not sure this works. There are additional attributes in the NAD (Via)
> > element that are currently required such as syncReply. Arvola. Can you ckeck
> > the spec and determine which is optional which is required and specify what
> > the default semantic should be for each of these elements/attributes if the
> > NAD/Via is not present.</db>
> >
> > Change 4
> > --------
> > Summary: Make the return of a Delivery Receipt required if
> > deliverySemantics=OnceAndOnlyOnce
> >
> > <df>Agreed</df>
> >
> > <ac>
> > I agree. Even if the incoming reliable message does not have
> > the DeliveryReceiptRequested attribute set, the receiver MSH
> > should still return a DeliveryReceipt.
> > </ac>
> > <db>I agree but is should be unsigned. This is the default value. See
> > below.</db>
> 
> <cf>
> I disagree! As I have repeatedly stated, the delivery receipt is
> not a function of RM. Do not tie the two together. If you want a
> deliveryReceipt, then ask for it using the existing mechanism
> (deliveryReceiptRequested). If you want that whenever you send a
> message with OnceAndOnlyOnce you ask for a deliveryReceipt, be my guest.
> 
> Please, do not make this a requirement.
> </cf>
> 
> >
> > Change 5
> > --------
> > Summary: Remove "None" as an option for deliveryReceiptRequested and make
> > deliveryReceiptRequested=false the default.
> >
> > Rationale: As the return of a Delivery Receipt is the only sure way that you
> > know a message was delivered suggests that it will be a simpler solution if
> > we make this always the case. Therefore we can make the return of a delivery
> > required if the deliverySemantics are OnceAndOnlyOnce. However you still
> > need to know if the receipt must be signed.
> >
> > <df>Agree with removing "None" but would prefer to leave as "Signed |
> > Unsigned"
> > for backward compatibility.  Default is "Unsigned".</df>
> >
> > <ac>
> > I agree with David Fischer.
> > </ac>
> > <db>So did I!</db>
> 
> <cf>
> Again, as I disagree with making a DR REQUIRED, I see no real value
> add in changing "None" to "false" unless the DR is ALWAYS signed
> in which case making the attribute an XSD boolean would make sense.
> </cf>
> 
> >
> > Change 6
> > --------
> > Summary: Make the return of an Acknowledgment element in a message required
> > if the ebXML RM protocol is being used
> >
> > <df>Agreed, but isn't this already true?</df>
> >
> > <ac>
> > I agree with David Burdett. The current spec does not required the
> > Acknowledgement element to be present in an Acknowledgement
> > message.
> > </ac>
> > <db>I agree with you and me ;)</db>
> 
> <cf>
> Huh? If the issue is that section 10.3.3 is less than clear as to whether
> an "Acknowledgment message" MUST have an Acknowledgment element, then
> clearly, that is an editorial issue that should be addressed. Seems
> to me that lines 1814/1815 should be changed to read:
> 
>         At a minimum, it MUST contain a MessageData element with a
>         RefToMessageId that is set to the value of the MessageId of
>         the message being acknowledged along with an Acknowledgment
>         element as described in section 8.6.
> </cf>
> 
> >
> > Change 7
> > --------
> > Summary: Remove "None" as an option for ackRequested and make
> > ackRequested=false the default.
> >
> > Rationale: The rationale for doing this is similar to changes 4 and 5. It
> > simply gives the rule that if you are doing ebXML RM then you must include
> > an Acknowledgment element in the response. The response can be synchronous
> > or asynchronous (see change 11 below).
> >
> > <df>Agree with removing "None" but would prefer to leave as "Signed |
> > Unsigned"
> > for backward compatibility.  Default is "Unsigned". (same as Change 5)</df>
> >
> > <ac>
> > I agree with David Fischer.
> > </ac>
> 
> <cf>
> Actually, consistent with the proposal I put forth above, adding a
> SOAP header block requesting an Acknowledgment would be a bit more
> coherent IMO.
> 
> e.g.
> 
>         <SOAP:Envelope xmlns:SOAP="...">
>           <SOAP:Header>
>             <eb:MessageHeader xmlns="...">...</eb:MessageHeader>
>             <eb:AckRequested xmlns:eb="..."
>                 SOAP:actor="http://.../next"
>                 SOAP:mustUnderstand="1"
>                 eb:signed="true|false"/>
>           </SOAP:Header>
>           <SOAP:Body>
>             <eb:Manifest xmlns:eb="..">...</eb:Manifest>
>           </SOAP:Body>
>         </SOAP:Envelope>
> 
> This approach is more consistent with SOAP and it eliminates the
> need to worry about ReliableMessagingMethod. It also provides for
> the Acknowledgment to be used for a foriegn specification for a reliable
> protocol that also used acknowledgments. For that matter, we could
> consider the AckRequested and Acknowledgment elements to be a
> SOAP module that is useful in and of itself. It could be essentially
> a self contained module with its own set of processing semantics
> specified, etc. IMO, this is a far cleaner and more modular approach.
> </cf>
> 
> >
> > Change 8
> > --------
> > Summary: Include automated retry by the original sender (From Party) if no
> > Delivery Receipt is returned
> >
> > <df>Agreed</df>
> >
> > <ac>
> > Do we need to give some guideline on the selection of retry interval
> > for hop-to-hop vs retry interval for end-to-end?  I think the former
> > interval
> > should be shorter than the latter.
> > </ac>
> > <db>Agree this would need to be included in the revised spec.</db>
> 
> <cf>
> I disagree for the reasons I've repeatedly cited. Absence of a received
> DR does NOT mean that the message hasn't been delivered. It only means that
> the sending party hasn't received a DR.
> 
> I would counter-propose the following:
> 
> - REQUIRE that ALL MSH nodes that receive a message with OnceAndOnlyOnce
>   deliverySemantics SHALL comply with the reliable messaging semantics
>   as defined in section 10. Further specify that any MSH node that
>   acts as an intermediary SHALL forward the message onto the next MSH
>   node using reliable messaging semantics as defined in section 10.
> 
> - REQUIRE that a DFN SHALL be sent to the From Party (section 10.4)
>   as requested by Marty if a message cannot be delivered.
> 
> - Clarify what "cannot be delivered", in section 10.4, means:
>         A message that is sent with deliverySemantics of OnceAndOnlyOnce
>         for which the MSH, after exhausting the specified number of
>         retries, separated by the specified retryInterval, has either
>         been unable to send (e.g. unable to establish a network connection
>         with the designated MSH node to which the message is to be delivered)
>         or for which no "Acknowledgment message" has been received.
> 
> - REQUIRE that a DR be delivered reliably (OnceAndOnlyOnce) if requested
> 
> - add a MSH "parameter" for DRTurnAroundTime or something like that
>   which the sending MSH uses to wait for a DR
> 
> - REQUIRE that the From Party's origin MSH notify the "From Party"
>   if the DRTurnAroundTime expires before receiving a DR
> 
> - let the "application layer" of software make the determination as
>   to whether or not it wants to resend the message, possibly using
>   an alternate delivery channel.
> 
> Please do keep in mind that a NRR/DR SHOULD be supported even if
> the deliverySemantics are BestEffort IMO. Let us not confuse these
> mechanisms.
> 
> Adding in the complexity of having to deal with intermediaries
> re-forwarding/processing messages for which no DR has been
> received would be a mistake IMO. It raises the bar on the complexity
> of an MSH considerably, especially for processing intermediaries
> as I have repeatedly pointed out.
> 
> If we stick with a store and forward, all nodes must adopt, protocol
> then if a message does not go through, there are WAY bigger problems
> than might be addressed by resending the message in any event.
> 
> </cf>
> 
> >
> > Change 9
> > --------
> > Summary: Include a "MessageRetryCount" in the NAD (was Via) element in the
> > Message Header
> >
> > Rationale: There is a need for automated retry by the original sender (From
> > party) if a Delivery Receipt is not received. However, the original sender
> > wants to send the **identical** message yet not have it treated as a
> > duplicate and by any intermediate MSH that has previously received it. To
> > solve this problem you can add a "MessageRetryCount" to the NAD which
> > indicates to the MSH that even though they have received the message before
> > they must still forward it.In this case even if the resend is received first
> > and the original appears some time later, the ToParty will be able to
> > recognize that the message has already been processed by comparing MessagIds
> > only and therefore the original should be ignored. This logic needs to be
> > included in section 10 and will need to include another level of
> > RetryCounts/RetryIntervals to work at the end-to-end rather than the
> > point-to-point level.
> >
> > <df>Agree on MessageRetryCount.  No need for another level of
> > Retries/RetryInterval since it already exists -- there is one set in the
> > end-to-end CPA (MessageHeader CPAId) and another in the Sender-FirstHop CPA
> > (Via
> > CPAId).</df>
> >
> > <ac>
> > I agree with David Fischer.
> > </ac>
> 
> <cf>
> As I said above, this raises the bar on complexity. You cannot use the
> same retries/retryInterval as for single-hop for starters. Consider a
> long chain of intermediaries which may have the ultimate recipient receiving
> the message after a significant passage of time for which the sending
> node wants to simply know when to stop resending (or trying to resend)
> the messsage to the first intermediate node.
> </cf>
> >
> > Change 11
> > ---------
> > Summary: Include syncReply at both the Message Header and the NAD/Via
> > elements
> >
> > The To Party needs to know whether the From Party wants the Delivery Receipt
> > and Business Payload assembled into one message.The next MSH needs to know
> > whether to send back an Acknowledgment synchronously or wait for the
> > Business Payload before sending it. The Delivery Receipt and Business
> > Payload can be sent asynchronously and the Acknowledgment sent synchronously
> > and vice versa as they are independent of each other.
> >
> > As you can't easily cover both requirements in a single element, they need
> > to be included separately in the header and in the NAD(Via).
> >
> > <df>Agreed</df>
> >
> > <ac>
> > I agree in general.
> >
> > The semantics of syncReply need to be aligned with the CPP/A spec.
> > The notions of signalsOnly, signalsAndResponse, and responseOnly
> > in the CPP/A spec need to be expanded to cover Acknowledgements
> > and DeliveryReceipt. Signals are application level messages according
> > to the BPSS spec.
> > </ac>
> > <db>I agree that the MS and CPPA specs need to be aligned.</db>
> >
> > Change 12
> > ---------
> > Summary: Clearly explain the relationship between applications, MSHs and
> > partys and the need for notification.
> >
> > Rationale: Marty Sachs has clearly demonstrated the absolute need to be
> > clear about stating the requirement that the From Party "knows" that the
> > message has been delivered. We need to clarify the spec to make sure that
> > this is clear.
> >
> > <df>Agreed.</df>
> >
> > <ac>
> > I agree.
> >
> > I also like to propose a Change 13. If ackRequested is implied whenever
> > deliverySemantics is onceAndOnlyOnce and reliableMessagingMethod
> > is ebXML, then there is no real need for an ackRequested attribute
> > (under the Via element).
> > <db>Disagree. You need to indicate whether it is signed or unsigned. With
> > the changes above, if it is absent, then it implies that it is
> > unsigned.</db>
> 
> <cf>
> Please see my proposal above.
> </cf>
> 
> >
> > If end-to-end reliable messaging does not imply hop-to-hop reliable
> > messaging, then we should clearly state that in the spec.
> > <db>Yes and no. I think that reliability works at two levels the hop and
> > point-to-point. They can actually work independently of each other as Dan
> > Weinreb has described.</db>
> >
> > Also, I believe in earlier discussions we have said that a Delivery
> > Failure Notification message from an intermediate MSH to the
> > sending MSH should be sent using reliable messaging. Such a
> > statement and the rationale for doing so should be incorporated into
> > section 10 as well.
> > <db>Agreed. Does the text contained in the email to Marty at
> > http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00365.html meet the
> > need? It proposes a revision to section 10.4</db>
> > </ac>
> 
> <cf>
> Agreed. However, I think that both DR and DFN should be delivered
> reliably. No DR for a DR though.
> </cf>
> 
> >
> > Product Manager, xCBL, XML Standards
> > Solution Strategy, Commerce One
> > 4400 Rosewood Drive, Pleasanton, CA 94588, USA
> > Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
> > mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
> >
> > ----------------------------------------------------------------
> > 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