[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 - Intermediaries/Message Status Request
Jim, If the IM node's MSH does not have the persistent store, then it is essential that the RM ACK be end to end. Of course all of the other concerns about multihop still apply even if the IM nodes MSH is full function. 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 ************************************************************************************* "HUGHES,JIM (HP-Cupertino,ex1)" <jim_hughes@hp.com> on 08/12/2001 11:11:45 PM To: ebxml-msg@lists.oasis-open.org cc: Subject: RE: T2 - Intermediaries/Message Status Request David, I'll let you guys that are more immersed in the specifics sort out how to identify a "router only". The branding or compliance question is: are you requiring that every MSH be able to do IM and end-point functions? Or, would it make this thing quite a bit more simpler if you just required that the IM be a "simple" MSH, and then specify a layer *above* the IM MSH to do the things that you want to do at the IM? Then, vendors can build routers to that additional specification plus the MSH spec. Alternatively, you could have the IM node *not* be a full-function MSH (for example, it doesn't have to have a persistent store and participate as an end-point in RM, and other things). Thus, you are either specifying a subset of our MSH spec (plus some new things, like routing functions) -- or making a separate spec for this architectural element. This is just a suggestion to make the conversation easier. I only have sporadic bandwidth to participate in these discussions, so I'd ask Ian to get this added to the regular topics... jim > -----Original Message----- > From: David Fischer [mailto:david@drummondgroup.com] > Sent: Sunday, August 12, 2001 7:59 PM > To: HUGHES,JIM (HP-Cupertino,ex1); ebxml-msg@lists.oasis-open.org > Subject: RE: T2 - Intermediaries/Message Status Request > > > Jim, > > We could make Via+Service=Route and Via+Action=Pass|Return > (or something like > that) for a Router Only. If Via+Service was something else > (e.g. TimeStamp) > then the IM MSH would participate in the BP. Is this what > you mean? The > Via+Service would then be the 'brand'. Or, did you mean make > some IM MSHs > unable to participate in the BP under any circumstances? > > Regards, > > David Fischer > Drummond Group. > > -----Original Message----- > From: HUGHES,JIM (HP-Cupertino,ex1) [mailto:jim_hughes@hp.com] > Sent: Sunday, August 12, 2001 2:40 PM > To: ebxml-msg@lists.oasis-open.org > Subject: RE: T2 - Intermediaries/Message Status Request > > > David - > > I have no doubt that one could think up functions for an IM. > The question is > whether, in ebXML messaging, we want to distinguish an > end-point-MSH from an > IM-MSH, or simply treat them all as instances of a 'branded' > MSH. All the > recent (and past) email traffic showing complex and varient > what-if cases > tells me we need simplicity in the architecture, at least for > the next round > of definition. Your suggestions below could well be value-add > layers above > the IM-MSH, not defined in our spec... > > jim > ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC