[ speaking as beep guy, and not co-chair... ]
I am just illustrating
XML/MIME exposure here. You can notice that we must use XML for BEEP
state management and we must use explicit Content-types for anything
other than application/beep+xml.
alex - perhaps a better way of explaining it is that each beep
interaction exchanges a mime object over an 8bit-clean path.
mime objects are serialized as some headers, e.g., Content-Type:, a
blank line, and then the body. the default content-type is
application/octet-stream, which means that if the serialized object
starts with a blank line, then
Content-Type: application/octet-stream
is assumed (not application/beep+xml). this is the "optimize for binary"
hack that dave crocker detests so much (dave doesn't like defaults).
the use of xml in beep can be limited to channel 0, which is used for
channel management (e.g., open a channel for doing ocp). otherwise, beep
really doesn't care how one structures the data it sends.
/mtr