On Thu, 24 Apr 2003, Marshall Rose wrote:
[ speaking as beep guy, and not co-chair... ]
Since Dave Crocker is not around, we can assume the above is the
default :-).
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.
Sorry I misread the default. This probably means even less overhead
for data exchanges over BEEP if OCP agents agree with that default.
My earlier examples lack
Content-Type: application/beep+xml
lines where XML is involved (because I incorrectly thought it was the
default type).
Thanks for clarifying this.
Alex.