[BXXPwg] Some recommendations regarding BXXP

Darren New dnew@san.rr.com
Mon, 14 Aug 2000 09:18:07 -0700


magdolna.gerendai@nokia.com wrote:
> What do you think about the other two recommendations: namely the
> transaction abort and channel close.

I think the channel close is a good addition. A negotiated close would be
necessary, as neither end can know if the other end has (for example) queued
a REQ for the channel that hasn't gotten to the head of the transmission
queue yet.

As far as aborting an RSP, I'm not sure that semantics could be defined that
would be useful in a wide variety of situations. You'd have to worry about
sending REQ 10, REQ 11, REQ 12, and then (say) trying to abort RSP 11 while
RSP 10 is still being returned? Should REQ 12 continue? Should REQ 11 be
rolled back? Should there be some sort of report about whether REQ 11 was
aborted in time?

I think if we had one-way messages (that didn't need a response) a profile
could define the semantics of aborting a request or a response, using the
new message type to pass an abort request, basically. But I think building
such a thing into the framework is going to lead to more problems than it
solves.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST).  Cryptokeys on demand.
"Do not install air conditioner in room with 
                    inconvenient or hypnotic persons."