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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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


Subject: Re: discussion priorities


Message text written by Henry Lowe
>For my dime, I'd rather have something like a reference to 
subheaders containing the routing info when you have a multi-hop.
That way, the usual simple 1-hop case uses the current "To" 
field (efficiently) and multi-hops point to an extended route 
in the message somewhere (no network accesses for routing info 
so efficiency isn't lost).  Of course, this needs to be extended 
a bit to cover routing failures and alternative routes.

Of course, there may be a better scheme as I haven't researched 
this topic or consulted with colleagues who are real routing 
gurus.  Anyone have a better wheel?

Hey, David, you didn't even need the steel vest :-)

Best regards,
Henry<

>>>>>>>>>>>>>>>>

Henry - today this routing stuff is handled by the network - it
figures out the beter route if a leg goes down.

Now that kind of PROFILE QoS is what you need - so I'd 
know what legs to use - presumably if you want totally
secure and authenticated this would limit the pathways.

I thkn this is all you REALLY care about - the QoS level,
so maybe this is the answer - exposing that in the header
and then letting the network delivery folks do the rest.

If you demand top level QoS that would presumably include
full tracking so if you need to you could audit where your message
went.

We could add this QoS stuff to the spec's - which is what I think
I hear others saying anyway.

DW.


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC