[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: non-ebXML links
Sorry, I am a bit behind on my email these days. See my comments below which may somewhat repeat ones that I just sent. 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 ************************************************************************************* Dan Weinreb <dlw@exceloncorp.com> on 09/15/2001 04:47:26 AM Please respond to Dan Weinreb <dlw@exceloncorp.com> To: dmoberg@cyclonecommerce.com cc: david@drummondgroup.com, david.burdett@commerceone.com, Martin W Sachs/Watson/IBM@IBMUS, chris.ferris@east.sun.com, arvola@tibco.com, ebxml-msg@lists.oasis-open.org Subject: non-ebXML links Date: Fri, 14 Sep 2001 09:39:35 -0700 From: "Dale Moberg" <dmoberg@cyclonecommerce.com> Dan Weinreb (I hope) said: "I think that someone reading the current ebXML MS spec, as it is currently worded, could easily be forgiven for thinking that there is no such concept as a "non-ebXML link in the path between two intermediaries". I don't think the existing spec, as currently worded, gives the reader any warning that such a thing is being contemplated." I agree that this idea is new to me. If there are such links, I think that they should have as much relevance as the fact that routers are routing IP packets between autonomous systems! We should be concerned with ebXML MS speakers, and the protocols for their message exchange(s). Actually, upon further reflection, I realize that my statement that the spec doesn't give you "any warning" is not correct. The warning is in these subsections: 8.7.4 reliableMessagingMethod attribute The reliableMessagingMethod attribute is an enumeration that SHALL have one of the following values: -- ebXML -- Transport The default implied value for this attribute is ebXML. 10.1.2 Methods of Implementing Reliable Messaging Support for Reliable Messaging MAY be implemented in one of the following two ways: -- using the ebXML Reliable Messaging protocol, or -- using ebXML SOAP structures together with commercial software products that are designed to provide reliable delivery of messages using alternative protocols. When I first read the spec I was somewhat confused by these sections. They could be interpreted as "scriptural basis" for Marty's position that we want to allow pairs of IM's to make independent choices about what protocol to use. MWS: I may be interpreting what other people are saying as allowing pairs of IMs to make independent choices and I have had suggestions as to how it might work. However as I noted in very recent posting, my real position is that our spec should concern itself only with a chain of ebXML nodes (ebXML MSH on both sides). Someone who builds a non-ebXML hop between two nodes that have MSHs on the outside has build a "virtual" ebXML node inside of which is a non-ebXML hop that is no business of ours. After all, section 10.1.2 clearly states that you MAY elect to *not* "use the ebXML Reliable Messaging protocol". This clearly implies that there is such a thing as "using the ebXML MS Spec protocol *but* *not* using the ebXML Reliable Messaging protocol". That clearly implies that there is a *distinction* between the former protocol and the latter protocol, so that you can be conforming to one while not using the other. It sounds paradoxical. But I think it makes complete sense in terms of the separation of layers that about which I've been running off at the mouth (at the keyboard?): we all share the higher layer, but we have a choice about the lower layer, and that's exactly the choice that these two subsections are talking about. Do we care about "scriptural basis"? Should we be in the role of rabbis or judges interpreting a scripture or law that we were given, or should we just be the legislators and decide as we choose to decide? Perhaps for release 1.1 we should tend more toward the former, and for 2.0 tend more towards the latter? It's not for me to say. MWS: We are the legislators, not the judges. The judges are the implementers. We must issue a body of commentary that aids the judges in building their products. This the text describing the responsibilities of intermediary nodes along with other explanatory text. Version 1.0 is indeed the "scriptural basis" for V 1.1 but as the legislators of V 1.0, we have the freedom of nullifying what we said in V 1.0 and for the sake of everyone's sanity (including our own), we should eliminate all mention of non-ebXML protocols. They are implementer choices, not part of the ebXML-MS spec. -- Dan ---------------------------------------------------------------- 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