The IESG has approved the following document: - 'Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP) ' <draft-thomson-beep-async-02.txt> as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thomson-beep-async-02.txt Technical Summary The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels. Working Group Summary This is an individual submission. Document Quality This was reviewed on the mailing list for the concluded BEEP WG. There was moderate controversy about whether this extension was needed as it is possible to work-around the lack of this feature in BEEP at the next layer up. No other technical objections were raised and there was explicit support from several parties. At least one open source BEEP library implementation has agreed to implement this extension. Personnel Chris Newman is the document shepherd. This has been reviewed for the IESG by Alexey Melnikov. Marshall Rose and other participants of the BEEP WG mailing list reviewed this proposal. RFC Editor Note Add at the end of Section 1 (Introduction) the following new paragraph: This document is published as an Experimental RFC in order to find out whether the extension is going to be deployed for use in a variety of use cases and applications. In section 3.1, 1st paragraph: OLD: The "feature" attribute in the BEEP greeting contains a whitespace separate list of features supported by each peer. If both lists ^ contain the same feature that feature may be used by either peer. NEW: The "feature" attribute in the BEEP greeting contains a whitespace separated list of features supported by each peer. If both lists ^ contain the same feature that feature may be used by either peer. Section 3.1, 2nd paragraph, 2nd sentence: OLD: If both peers include this feature in the greeting message, either peer is able to create an asynchronous channel. NEW: If either peer does not include this feature in the greeting message, neither peer is able to create an asynchronous channel. Add a new Section 3.4 with the title "Error handling" BEEP does not provide any mechanism for managing a peer that does not respond to a request. Synchronous channels cannot be used or even closed if a peer does not provide a response to a request. The only remedy available is closing the underlying transport. While an asynchronous channel cannot be closed, it can still be used for further requests. However, any outstanding request still consumes state resources. Client peers may dispose of such state after a configured interval, but must be prepared to discard unrecognized responses if they do so. In Section 5, replace the 2nd paragraph with the following 2 paragraphs: OLD: Peers that serve requests on asynchronous channels are not subject to any specific problems from state accumulation. Peers in the serving role are able to use flow control [RFC3081] to limit the consumption of local resources. NEW: A client peer maintains state for each request that it sends. A client peer should enforce a configurable limit on the number of requests that it will allow to be outstanding at any time. This limit could be enforced at channel, connection, or application scope. Once this limit is reached, the client peer might prevent or block further requests from been generated. Peers that serve requests on asynchronous channels also accumulate state when a request is accepted for processing. Peers in the serving role may similarly limit to the number of requests that are processed concurrently. Once this limit is reached the receiving peer can either stop reading new requests, or might start rejecting such requests by generating error responses. Alternatively, the flow control [RFC3081] can be used; SEQ frames can be suppressed, allowing the flow control window to close and preventing the receipt of further requests. "an BEEP" --> "a BEEP" (2 cases: 1 in the Abstract and 1 in the Introduction) "an means" --> "a means" (in Section 3) In Section 1, 4th paragraph: "only requests may be processed" --> "except that requests may be processed" _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
