[BEEPwg] DIME

Gabe Wachob gwachob@wachob.com
Mon, 4 Feb 2002 08:23:20 -0800 (PST)


Edd-
	DIME is closer to "MIME with chunking" (or more accurately, a MIME
container) than frames in BEEP (from my general understanding of DIME and
a quick scan of this I-D). DIME chunking is like HTTP chunking (chunked
content-encoding) in the sense that I *think* its meant as an efficiency
mechanism to allow sending applications to send data "buffer-by-buffer"
rather than having to buffer an entire piece of content on the sending
side (to determine size) before beginning to send the content. (See
section 1.2, design goal #2)
	Also, DIME is intended for SOAP (at least thats the context I know
it from) and as such the motivations for Frame(s) in BEEP are absent from
the context of DIME. That is, DIME wouldn't be usable for things like flow
control or even managing network buffers, etc, primarily because DIME is
presumably visible at a relatively high level of abstraction (though this
is implementation dependent I guess). That is, DIME is defined
irrespective of the type of transport (one can send SOAP with DIME over
SMTP, for example). While one could define a BEEP/SMTP binding, the
motivation for Frames there would probably go out the door (along with
all of BEEP).

	Hope this is helpful... Maybe there are some similarities I'm not
catching..

	-Gabe

On 4 Feb 2002, Edd Dumbill wrote:

> Hello BEEPers,
>
> I just came across
> http://discuss.develop.com/archives/wa.exe?A2=ind0202a&L=dime&F=&S=&P=304
> and more particularly
>
> http://www.gotdotnet.com/team/xml_wsspecs/dime/draft-nielsen-dime-01.txt
>
> [[[Abstract
>
>      Direct Internet Message Encapsulation (DIME) is a lightweight,
>      binary message format that can be used to encapsulate one or more
>      application-defined payloads of arbitrary type and size into a
>      single message construct. Each payload is described by a type, a
>      length, and an optional identifier. Both URIs and MIME media type
>      constructs are supported as type identifiers. The payload length is
>      an integer indicating the number of octets of the payload. The
>      optional payload identifier is a URI enabling cross-referencing ]]]
>
> >From first glance this looks to be akin to BEEP framing, but I could be
> wrong.  Another thought that occurred to me is that it's a way to get
> rid of the issues sending binary objects with SOAP.
>
> I'd be interested in the BEEP perspective on this I-D.
>
> cheers
>
> -- Edd
>

-- 
Gabe Wachob                   gwachob@wachob.com
Personal                   http://www.wachob.com
CTO, WiredObjects    http://www.wiredobjects.com