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 - 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