Re: caching and compression profiles?
Marshall Rose <[email protected]>
| Newsgroups | gmane.ietf.beep |
|---|---|
| Organization | Dover Beach Consulting, Inc. |
| Message-ID | <[email protected]> |
[ eric rescolra added to thread... ] eric - what's the story on TLS use of compression? is it automatic, if available? or is there some other "magic" involved. ryan - i think that caching and compression are probably two different things. caching is probably profile-specific in the sense that whatever does the caching has to understand the semantics of the profile in use on the channel. compression is more general. i suppose you could do it either as a tuning profile (for the whole session) or on a per-channel basis. i can see advantages to each, but i'd prefer that the result look like this: 1. if you tune for privacy, then session-wide compression should just happen automatically, as a part of the security layer. 2. if you don't tune for privacy, then you may decide to tune for compression. it should be fairly easy to define a family of profiles to do this, e.g., http://.../zlib, http://.../my-whacky-compression, etc. if someone feels strongly that compression ought to be done on a per-channel basis, then we'll finally get a chance to use BEEP's feature negotiation mechanism, because there'll have to be a way of letting the two sides negotiate the use of compression before they start adding a "Content-..." header to the messages they exchange over BEEP... /mtr > Has anyone thought about writing a zlib profile to do gzip compression? > What about a profile to do caching? Is there any reason profiles like > this couldn't be created? > > It seems like a compression profile would be straightforward and useful > enough that someone may have already done this. > > In my case I would like to send a large amount of xml messages (IDMEF) > from a client to a server. Using gzip I can usually get around 30x > compression. I'd imagine that XMill or some other approach could do > better. For security reasons I'd like to use the tls profile (actually > the idxp profile with tls). Besides network bandwidth there are > performance and security reasons why compression is attractive. > > I could turn on compression in openssl in both the client and the > server machines but that is implementation specific and not general > purpose. I could also compress/decompress the messages in the > applications - but this ties clients to servers and kinda defeats the > purpose of using an open format like IDMEF. I think a compression > profile would be the best solution and allow peers to negotiate a > compression profile when it is available on the client and the server. > > I did a quick search and found a refernce to a suggestion for a > compression profile in the mailing list archive, whatever happened to > that idea? > If a compression profile could be written it wouldn't work very well > with small messages, that is where a caching profile might be useful - > cache messages and compress a bunch of them at once. > > What do you people think? > > Ryan > > _______________________________________________ > BEEPwg mailing list > [email protected] > http://lists.beepcore.org/mailman/listinfo/beepwg