Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)
RFC 5573

Note: This ballot was opened for revision 02 and is now closed.

Alexey Melnikov Yes

Comment (2009-05-07)
No email
send info
In response to Lisa's concerns:

[22:04:40] <Chris Newman> Lisa is also incorrect that there's no benefit for the receiver.
[22:04:51] <alexeymelnikov> What is the benefit?
[22:08:55] <Chris Newman> So with channels, the receiver will typically want to implement one thread per channel to keep things simple. For this extension, the receiver will implement a work queue and dynamically create or reuse idle threads as needed. The receiver can control how many worker threads it wants to create for the work queue, so it can dynamically adjust to load. That's much more difficult with a channel-based architecture. Channels also have a lot more receiver-side state.

Later on Chris said:

[22:23:57] <Chris Newman> BEEP channels are stateful asynchrony, Async requests are stateless asynchrony. Both are beneficial for different use cases for both parties. 

Also, a similar feature is present in both base XMPP, IMAP and LDAP. It is used heavily in XMPP and LDAP. I was thinking to take advantage of it in Isode's IMAP server, for example for out of order processing of full body searches over multiple email messages.


Note to myself:
Add an RFC Editor note about use cases.

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) (was Discuss) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) No Objection

(Adrian Farrel) No Objection

Comment (2009-05-04)
No email
send info
If you are making edits...

s/an BEEP/a BEEP/ twice
s/an means/a means/

Section 1
s/only requests may be processed/except that requests may be processed/

Section 3.1
It might be nice to state explicitly the converse of...
   If both peers include
   this feature in the greeting message, either peer is able to create
   an asynchronous channel.
That is:
   If either peer does not include
   this feature in the greeting message, neither peer is able to create
   an asynchronous channel.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

Comment (2009-05-05)
No email
send info
The archives for BXXP have moved away from the link the charter and tools page point to. I was able to find them (I think) by digging around at beepcore.org <http://www.beepcore.org/old-archives/beepwg/pipermail/beepwg/>. Is there a better store somewhere?

Magnus Westerlund No Objection