[BXXPwg] Some recommendations regarding BXXP

magdolna.gerendai@nokia.com magdolna.gerendai@nokia.com
Mon, 14 Aug 2000 18:54:36 +0300


Hi Cris,

The profile seems to be a good idea for "out of order" negotiation. 

What do you think about the other two recommendations: namely the
transaction abort and channel close. The current situation is, that if a RSP
has been started, no way to stop it, because there is no way even to close
the channel. But a channel close (if it exists) requires additional
unnecessary overhead to start a new one only for suppress a RSP not
required.

I think, we could also specify profile for compression, independently from
any security profile. It could solve the compression of the whole data
structure in the message body (i.e. if it has a header+data structure, it
could compress the header part as well).

br,
Magdolna  

> -----Original Message-----
> From: EXT Chris Hanson [mailto:cmh@bDistributed.com]
> Sent: 12. August 2000 23:58
> To: bxxpwg@invisible.net
> Subject: Re: [BXXPwg] Some recommendations regarding BXXP
> 
> 
> At 4:12 PM +0300 8/10/00, magdolna.gerendai@nokia.com wrote:
> >2.) I don't understand, why the pipelining behaviour is, the 
> requests and
> >responses could come out of order ( the fragments as well). 
> The serial
> >number, (the channel number) and seqno unambiguously 
> identifies  , which REQ
> >or RSP the fragment belongs to. This gives the possibility 
> of the real
> >asynchronous transactions. In some use cases this may have 
> importance.
> 
> I agree.  I think it should be up to a particular profile whether or 
> not responses should be issued in order, rather than the higher-level 
> application protocol.
> 
> Say you're designing an instant messaging protocol on top of BXXP.  A 
> client could issue a "subscribe to group foo@bar.org" command, and 
> then wait for responses to it.  One response might be "subscription 
> request successful," and subsequent responses might be "message 
> posted to foo@bar.org".  There's no reason why clients and servers 
> shouldn't be able to handle these responses concurrently with other 
> responses, regardless of the order in which they're received.
> 
> This type of functionality is similar to IMAP and ACAP's "untagged" 
> responses, and could be very useful to higher-level protocol 
> designers.  I know it's something people designing RPC-oriented 
> protocols are very interested in.
> 
>    -- Chris
> 
> -- 
> Christopher M. Hanson
> President
> bDistributed.com, Inc.
> cmh@bDistributed.com
> 
> _______________________________________________
> BXXPwg mailing list
> BXXPwg@lists.invisible.net
> http://lists.invisible.net/mailman/listinfo/bxxpwg
>