[Vortex] Are content-types and transfer-encodings supposed to work?

[Robert M. Münch]

On Tue, 13 May 2008 21:34:07 +0200, Jens Alfke <jens at mooseyard.com> wrote:

> I want to compress some message bodies (using gzip). I'm sometimes
> bandwidth-constrained, and markup like XML / JSON / YAML compresses
> extremely well (sometimes 10::1.) The most natural way to do that
> would be for the sender to add a "Content-Transfer-Encoding: gzip"
> header, as HTTP does.

Hi, ok, why not compress them all the time? This reduces complexity and  
variants to handle. I always try to keep things as simple as possible and  
a correct MIME implementation seems to be quite difficult.

As long as your app is only talking to a server from you, you could skip  
all this. Maybe it's not interoperable with other BEEP clients. But the  
tricks is in the application protocol, which must be special handled  
anyway.

> Without that, I have to do something like insert a flag byte in front
> of the payload that's set to 1 if the payload is zipped. Yuck.

Or zip it all the time. Than it's clear what's on the wire. That's what I  
do.

> In general, BEEP was intended to save people from having to re-invent
> the same wheels over and over. Inventing new data formats and
> conventions for annotating data is a major source of that.

Yes, I agree.

> It's a lot cleaner if you can send the payload in a standard format,  
> whether it's
> XML or JPEG or whatever, and have a mechanism for attaching metadata
> to it, like types and encodings and dates and whatever. That's been
> ubiquitous ever since at least RFC 822.

Adding metadata is the main value I see of using MIME as long as  
additional keywords are handled correctly.

But I hope this isn't a showstopper for you. Robert