Re: DIME Use Case?

>MIME is created for the same thing DIME is.

Nope, DIME is explicitly not designed to be an open-ended description format. You can profile MIME as much as you like, it is still an open-ended description format and very successful at that. It is absolutely not the intent of DIME to change the usage of MIME at all but rather to provide a simple wrapper.

> Like many other
>people say beside Erik and myself, with MIME you can have a 
>profile which need binary transport (including a 
>content-length tagging if you want) and voila, you have what I 
>claim is so close to DIME that DIME is not needed.

But then it's not MIME anymore. This was discussed at length in connection with HTTP - I think you were part of that discussion and might recall the friction it caused between HTTP and MIME. Further, merely adding content length is not sufficient given that we know the problems it causes with large amount of data being generated dynamically.

>Also, regarding basic transport, look at the blocks
>architecture, it is exactly what DIME want to be (I claim) but 
>with more features which solves other problems you still will 
>have with DIME, like multiplexing over the same connection.

Absolutely not - DIME does in no way attempt to provide a stateful, layered multiplexing protocol layer. As has been mentioned, DIME is not a protocol and deliberately avoids the problems of layered multiplexing because of the inherent problems this has shown to produce [1][2].

Henrik

[1] http://tns-www.lcs.mit.edu/publications/multiplexing89.html
[2] David Feldmeier, Multiplexing Issues in Communication System Design, SIGCOMM 1990.
[3] http://discuss.develop.com/archives/wa.exe?A2=ind0204b&L=dime&F=&S=&P=494