FW: Protocol Action: (BEEP/Blocks/BXXP) to proposed standard

Of possible interest to XML Protocol work...

-----Original Message-----
From: scoya@cnri.reston.va.us On Behalf Of The IESG
Sent: Monday, January 22, 2001 10:27 AM
To: IETF-Announce:
Cc: RFC Editor; IANA; Internet Architecture Board; bxxpwg@INVISIBLE.NET
Subject: Protocol Action: Mapping the BXXP Framework onto TCP to Proposed
Standard




The IESG has approved the following Internet-Drafts for publication as
Proposed Standards:

o The Blocks Extensible Exchange Protocol Framework
	<draft-ietf-beep-framework-11.txt>

o Mapping the BXXP Framework onto TCP
	<draft-ietf-beep-tcpmapping-06.txt>

These documents are the product of the Blocks Extensible Exchange
Protocol Working Group.  The IESG contact persons are Ned Freed and
Patrik Faltstrom.


Technical Summary

   BEEP provides a generic application protocol framework for
   connection-oriented, asynchronous interactions.

   At the core of the BEEP framework is a framing mechanism that
   permits simultaneous and independent exchanges of messages between
   peers. Messages are arbitrary MIME[1] content, but are usually
   textual (structured using XML[2]).

   All exchanges occur in the context of a channel -- a binding to a
   well-defined aspect of the application, such as transport security,
   user authentication, or data exchange.

   Each channel has an associated "profile" that defines the syntax and
   semantics of the messages exchanged. Implicit in the operation of
   BEEP is the notion of channel management. In addition to defining
   BEEP's channel management profile, this document defines:

   o  the TLS[3] transport security profile; and,

   o  the SASL[4] family of profiles.

   Other profiles, such as those used for data exchange, are defined by
   an application protocol designer.

Working Group Summary

   The BEEP WG expanded on the BLOCKS protocol work done by Marshall Rose and
   Carl Malamud. BLOCKS in turn drew on many existing IETF protocols and
   the design goals discussed at the APPLCORE BOF.

Protocol Quality

   Ned Freed reviewed the BEEP specification for the IESG.


Note to RFC Editor:

  In draft-ietf-beep-tcpmapping-06, please add the following paragraph
  just after the two bullet items in section 2:

	A simultaneous TCP OPEN would result in both BEEP peers believing
	they are the initiator and neither peer will be able to start any
	channels. Because of this, services based on BEEP must be designed
	so that simultaenous TCP OPENs cannot occur.

Received on Monday, 29 January 2001 04:25:49 UTC