[BXXPwg] Some recommendations regarding BXXP

magdolna.gerendai@nokia.com magdolna.gerendai@nokia.com
Mon, 14 Aug 2000 22:17:52 +0300


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

Yes, I agree, a profile can solve the problem.

br,
Magdolna

> -----Original Message-----
> From: EXT Darren New [mailto:dnew@san.rr.com]
> Sent: 14. August 2000 18:18
> To: magdolna.gerendai@nokia.com
> Cc: bxxpwg@invisible.net
> Subject: Re: [BXXPwg] Some recommendations regarding BXXP
> 
> 
> 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."
>