NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 30-Oct-00
Keith McCloghrie <firstname.lastname@example.org>
Applications Area Director(s):
Ned Freed <email@example.com>
Patrik Faltstrom <firstname.lastname@example.org>
Applications Area Advisor:
Ned Freed <email@example.com>
To Subscribe: firstname.lastname@example.org
Description of Working Group:
The IETF BEEP working group shall develop a standards-track application protocol framework for connection-oriented, asynchronous request/response interactions.
The framework must permit multiplexing of independent request/response streams over a single transport conneciton, supporting both textual and binary messages.
The working group will use BXXP (as described in draft-mrose-bxxp-framework and draft-mrose-bxxp-tcpmapping) as its starting point. Although not encouraged, non-backwards-compatible changes to BXXP will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them.
Goals and Milestones:
Prepare updated specification reflecting issues and solutions identified by the working group
Discuss and revise Internet-Draft at the Pittsburgh IETF
Submit revised specification to the IESG for consideration as a standards-track publication.
No Request For Comments
BEEP WG, Thursday 14 December, 1530-1730
1. Agenda bashing
2. WG status - Keith McCloghrie
3. Review of BEEP - Marshall Rose
4. Multi-peer application protocols - Dan Li
5. Discussion and Q&A
After a slight reordering of the agenda, Keith presented the WG status. The WG's two Internet-Drafts (draft-ietf-beep-framework-nn.txt and draft-ietf-beep-tcpmapping-nn.txt) have completed WG Last Call and IETF Last Call, and are now awaiting the IESG's formal decision before they become Proposed Standards. The other two I-D's of relevance to the WG are draft-mrose-beep-design-01.txt which Marshall and Carl will publish as an Informational RFC, and draft-mrose-beep-sctpmapping-00.txt for which Marshall is waiting on an action by the SCTP folks. Thus, none of the four I-D's needed any discussion at this meeting. So, the focus of this meeting was for the benefit of implementors (as opposed to making progress on the charter of the WG).
Next, Marshall presented his review of BEEP. He covered much the same material as in the previous WG meeting, but it was updated based on the changes adopted by the WG since last Summer. Several issues came up during the presentation:
1. The notion of mapping a BEEP session onto multiple TCP connections is still under consideration by Joe Touch. Joe confirmed that this work was pending finalization of the framework.
2. For one-to-one exchanges, there is a positive reply (the "RPY" message) and a negative reply (the "ERR" message). However, for the one-to-many exchanges, the replies consist of zero or more "ANS" messages followed by a "NUL" message. That is, a negative reply can not be generated after one or more "ANS" messages have been sent. Further discussion of this issue was deferred to the end of the meeting.
3. It was suggested that the "best current practices" for implementing the transport mappings should be documented. It was agreed that this can be done (based on implementation experience) in a future revision of the transport mappings document(s), e.g., advice of how to implement BEEP's flow control.
Dan Li then presented some requirements for a multi-peer application (see draft-danli-wrec-wcip-00.txt). The basic requirement would appear to be the need for a "logical bi-directional channel" consisting of multicast downstream and unicast upstream.
Discussion then returned to the issue of whether the "ERR" message should be allowed (as an alternative to a "NUL" message) in one-to-many exchanges. The chair observed that this was not a new issue; the Working Group had discussed it at least once before on the mailing list and decided in favour of the approach in the current documents. However, there was some confusion (at the meeting) on what the current documents indicate. At least one group argued that "ERR" messages convey BEEP-layer errors only, and that application-specific errors are conveyed by "RSP" or "ANS" messages. Joe Touch believed the current documents indicated otherwise; that the ERR messages include application errors. After some discussion, the (non-unanimous) consensus was to go/stay with the former approach, and ask the editor to see whether some clarifying text could be added to the framework document as an editorial change.
Review of BEEP