Subject: [BEEPwg] DIME

From: Edd Dumbill <[email-masked]>
Date: 04 Feb 2002 10:28:24 +0000

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

---

From: "Marshall T. Rose" <[email-masked]>
Date: Mon, 4 Feb 2002 08:17:47 -0800

ed - dime is an alternative for multipart/mixed, obstensibly motivated by
the "binary objects" with soap problem that you mentioned. there is a second
draft, draft-nielsen-dime-soap-00, which talks about using dime to encode
soap.

neither of these drafts have any "control" component, as such, they are akin
to mime, not beep.

one could certainly define a beep "profile" to transport soap encoded using
dime, just as there's one for transporting soap encoded using mime...

/mtr

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: Gabe Wachob <[email-masked]>
Date: 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

-- 
Gabe Wachob                   [email-masked]
Personal                   http://www.wachob.com
CTO, WiredObjects    http://www.wiredobjects.com