NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Chair(s):
Keith McCloghrie <kzm@cisco.com>
Applications Area Director(s):
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Ned Freed <ned.freed@innosoft.com>
Mailing Lists:
General Discussion:bxxpwg@invisible.net
To Subscribe: bxxpwg-request@invisible.net
Archive: http://lists.invisible.net/pipermail/bxxpwg/
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:
Jul 00 |
|
Prepare updated specification reflecting issues and solutions identified by the working group |
Aug 00 |
|
Discuss and revise Internet-Draft at the Pittsburgh IETF |
Jan 01 |
|
Submit revised specification to the IESG for consideration as a standards-track publication. |
No Current Internet-Drafts
No Request For Comments
BEEP Working Group
Minutes of meetings at Pittsburgh IETF (August 2000)
Agenda
- review of agenda
- review of BEEP: design, framework, and TCP-mapping - Marshall Rose
- prepared presentations
- Issues List - Marshall Rose
- Mapping LDAP onto BEEP - Kurt Zeilenga
- suggestions/comments from the floor
- disposition of Internet-Drafts
- wrap-up
First session (Thursday 4th August)
As an introduction, Keith McCloghrie reviewed the charter and milestones for the WG. Marshall Rose then presented a review of BEEP, the rationale for its design choices, the framework for the protocol, and its mapping on top of TCP. In addition to clarifying questions, several suggestions were made during the presentation:
- it was suggested that some transport mappings will be able to get indications of network congestion (e.g., via "Congestion Manager"), and therefore that it would be useful for the interface between the framework and a transport mapping to allow the transport mapping to pass up an indication of network congestion.
- for security, it was asked whether it's possible to start TLS first, and then run BEEP over top of it, rather than not being able to start TLS until after some BEEP messages have already been exchanged. Marshall clarified that it's not currently possible, but he would think about whether it could be made possible. Marshall also clarified that it's not possible to do encryption on a per-channel basis, i.e., that negotiation of encryption applies to all channels.
Marshall then presented a list of issues that had been raised on the mailing-list prior to the meeting. He listed the issues in five categories: Framing, Profiles, Channel Management, Reporting and TCP mapping.
A) Framing Issues
1) Serial/Sequence numbers - BEEP's inclusion of serial and sequence numbers in its message header format could be viewed as redundant information. However, they ensure that the communicating applications will detect situations in which they become unsynchronized. That is, sequence and serial numbers provide robustness in the form of catching application-programming errors. In addition, Marshall cited his practical experience of catching such errors during interoperability testing of BXXP implementations. It was pointed out that the degree of redundancy is dependent on the transport mapping, and that different header formats for different transport mappings is undesirable for many reasons, e.g., because it complicates encoding and parsing. Therefore, the consensus of the meeting was to keep the serial and sequence numbers as-is.
2) Invalid RSPs - the framework does not specify what happens when a channel gets an invalid RSP. It was agreed that an invalid RSP on channel zero should cause the whole session to be aborted. However, it is unnecessary to abort the whole session for an invalid RSP on a non-zero channel; rather, it is only neccesary to abort the individual channel. Therefore, the consensus of the meeting was to generate a diagnostic message, and to shut down a non-zero channel on which an invalid RSP was received.
3) MIME headers only in first frame of a message - the framework does not explicitly explain this requirement. It was observed that the scope of these MIME headers is limited, and so, it's unlikely that they could be large (e.g., larger than the size of a frame). Nevertheless, they enjoy a "free ride" from a flow-control perspective, because they are part the header, not part of the payload, and therefore not subject to flow-control. Therefore, the consensus of the meeting was that the framework document does need to add explanatory text about this issue.
4) REQs and RSPs - the framework requires that each REQ have one and only one RSP. Discussion of this issue led to several examples of applications which have a different requirement:
- a logging application, which does not need an application-level acknowledgement for each log message it sends; this was described as the "1-to-0" requirement (one REQ with no RSP).
- a status reporting application, where a request for status invokes multiple periodic responses, e.g., a RSP providing status every 10 seconds; this was described as the "1-to-N" requirement (one REQ with many RSPs).
Several mechanisms were suggested to address these requirements. It was proposed that a solution should avoid the sending of useless/redundant messages.
Second session (Friday 5th August)
Kurt Zeilenga gave a presentation of issues he had found in investigating how to map LDAP on top of BEEP. He stated the primary issue as being the number of situations where LDAP interactions are not one REQ to one RSP. In particular, he gave "persistent search" as an example of a 1-to-N requirement, and "unsolicited responses" as an example of a 1-to-0 requirement.
Marshall then continued to present the Issues List.
4). REQs and RSPs (continued) - The consensus of the meeting was to accept the "1-to-0" and "1-to-N" requirements, and to request volunteers to work offline on a solution, and then send to the mailing-list. Joe Touch volunteered to prepare a proposal.
B) Profile Issues
1. Default Content Type - should a profile be allowed to specify a default Content Type. By having a default, an application would not have to send a Content Type every time it opened a channel, which could save, say, 40 bytes. On the other hand, always having the Content Type explicitly specified would simplify the task of a "debugger" being used to capture all exchanges on the BEEP session by capturing packets "on the wire". Thus, this issue is a trade-off between "reducing the number of bits on the wire" versus "ease of debugging". A show of hands determined that there was no consensus in the meeting on which choice was better. Thus, this issue was deferred for discussion on the mailing list.
2. Default Character Set - should an XML-based profile be allowed to specify a default character set. One suggestion was to discourage the use of anything other than UTF-8. However, it was pointed out that the argument in favour of UTF-16 is that Asian characters can be represented in only 2 bytes in UTF-16 instead of 3 bytes in UTF-8 (although other considerations cause the overall length of encodings to even out overall). The consensus of the meeting was for all XML-based profiles to have a default of UTF-8, i.e., not to allow each profile to have its own default. However, if an XML-based profile needs to specify an alternative character set, it should use a Content-Type header to do so.
C) Channel Management Issues
1. Closing Channels - should the framework allow channels to be closed. Such a mechanism will be useful for the transport mappings to know traffic has ceased on a channel (so that buffers can be released), and the closing of a channel will allow its re-use. Having a Close Channel will also provide the means to send diagnostic information and to shut-down a non-zero channel (see the "Invalid RSPs" issue above). This led to discussion of allowing more than 255 channels. When running over TCP, channels will be able to be re-used faster than TCP ports can be re-used (because of TCP's TIME-WAIT state). Therefore, the size of the channel number space should be larger than the number of TCP ports. Thus, it was suggested that a channel number be up to 31 bits wide. However, it was also suggested that the minimum number of concurrently open channels supported by an implementation need only be 257. The consensus of the meeting was to introduce a Close Channel mechanism able to include diagnostic information, to allow 31 bits of channels number with a minimum of 257 concurrently open channels.
2. Piggybacks - an XML-based profile is allowed to include an encapsulated message as part of channel creation. This piggybacking capability saves a round trip time, and that was thought to be a good thing for some transport mappings, e.g., T/TCP or UDP. However, implementations should not send an "unreasonable" amount of data in the <start>. The consensus of the meeting was to retain piggybacks, and to add text to the specification reminding profile designers that initialization elements should be reasonable in size.
D) Reporting Issues
1. Error code - should channel-0 as well as the SASL and TLS channels use three digit error codes. It was agreed that the hierarchical model of the three digit codes was good, and that having textual messages for humans in addition to the machine-readable 3-digit error codes was good. The consensus of the meeting was for no change.
E) TCP Mapping Issues
1. Silly Window Syndrome - should the TCP mapping document include text similar to RFC 1122 to explain SWS. The consensus of the meeting was to cite RFC 1122 and to explain the context of how it applies to BEEP, i.e., the same except for retranmissions.
2. Shrinking the Window - should the TCP mapping document include words similar to RFC 1122 on allowing the window's right-hand edge to move only to the right. The consensus of the meeting was to cite RFC 1122 and to explain the context of how it applies to BEEP, i.e., the same but there's no "congestion window".
Suggestions from the Floor
It was suggested that having the channel number in RSP messages would simplify an implementation. The alternative perspective was that the channel number of a received RSP is easy to obtain through looking up the RSP's serial number. The ability of a debugger capturing "on the wire" packets was again cited as being simpler if it did not have to see as many packets, nor keep as much state. Thus, the consensus of the meeting was to include the channel number in the RSP message.
This led to the suggestion that the serial number no longer needs to be unique per session, only unique per channel. It was observed that this would make it simpler for multi-threaded implementations. Therefore, the consensus was that message serial numbers only need to be unique within a channel.
Disposition of Internet Drafts
It was observed that the design document, draft-mrose-bxxp-design-00.txt, is written as Marshall and Carl's rationale for the design of BXXP, which is the starting point of the Working Group's effort. Thus, it is not appropriate for it to become a standards-track document, nor for it to be a WG document. Instead, it was agreed that the authors be thanked for their input and allowed to publish it in whatever way they wish, e.g., the WG would be quite happy for it to be published as an Informational RFC.
The framework and TCP-mapping documents, draft-mrose-bxxp-framework-01.txt and draft-mrose-bxxp-tcpmapping-01.txt, were adopted as WG documents, and Marshall will update them based on the consensus of the WG. The consensus of the WG will be as recorded in the minutes and as modified by discussion, if any, of the minutes on the mailing-list.
Marshall explained that the initial attempt at a SCTP-mapping document, draft-mrose-beep-sctpmapping-00.txt, needs further work. As such it will be adopted as a WG document, but could have significant revisions at a later date.
The WG welcomed Joe Touch's offer to start work on a transport mapping document for BEEP over "multiple TCP connections". Work on a transport mapping document for BEEP over UDP was deferred. Joe Touch also stated his intention to make a proposal for being able to turn off encryption on a per-channel basis.
(Minutes recorded by Keith McCloghrie.)