RE: TID Label Issues - Issue #2

Bidulock,


There are many options in the SUA spec that are designed for a specific
solution in mind.  In some applications, we use override, some
loadshare, some route on GT, some route on TID.  Again, this is a
solution for a specific set of application and it works for those.  I
didn't say that TID should be used for everything.  I'm not going to use
DRN routing for Class 1 messages obviously.  And I'm not going to solve
use just TID routing to solve linked transactions.  

Since there is no RFC to solve linked transactions, right now we must
solve them on our own.  And we have.  We used TID routing with a
proprietary mechanism that ensure that the messages arrive at the
correct ASP.

Regards,
Lincoln

 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Wednesday, October 11, 2006 4:11 PM
To: Haresign Lincoln
Cc: Barry Nagelberg; [email protected]
Subject: Re: TID Label Issues - Issue #2

Haresign,

Haresign Lincoln wrote:                      (Wed, 11 Oct 2006 15:57:34)
> Brian,
> 
> I don't believe that the SUA spec handles this at all.  We have 
> designed a proprietary mechansim that works with Correlation Ids 
> within the message.

Not interoperable.

> 
> I think the TID routing mechansim (like other options in the spec) are

> designed for certain mechanisms.  More advanced features (like linked 
> transactions via a correlation ID or Billing ID) require either a 
> proprietary mechanism or a new RFC.
>
> However for applications that don't have linked transactions, the TID 
> routing works quite well.

My point, the mechanism is broken and does not work for any but a
restricted range of TID applications, and only then it seems when
proprietary deviations from the specification are in place.

--brian

--
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/