[BXXPwg] Some recommendations regarding BXXP
Mon, 14 Aug 2000 18:54:36 +0300
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
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).
> -----Original Message-----
> From: EXT Chris Hanson [mailto:cmh@bDistributed.com]
> Sent: 12. August 2000 23:58
> To: email@example.com
> Subject: Re: [BXXPwg] Some recommendations regarding BXXP
> At 4:12 PM +0300 8/10/00, firstname.lastname@example.org 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
> 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 email@example.com" command, and
> then wait for responses to it. One response might be "subscription
> request successful," and subsequent responses might be "message
> posted to firstname.lastname@example.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
> bDistributed.com, Inc.
> BXXPwg mailing list