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 <> on 09/15/2001 04:47:26 AM
Please respond to Dan Weinreb <>
To:
cc:
, , Martin W
Sachs/Watson/IBM@IBMUS, , ,
Subject: non-ebXML links
Date: Fri, 14 Sep 2001 09:39:35 -0700
From: "Dale Moberg" <>
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>
