Subject: RE: [lemonade] LEMONADE WG Media Conversion Summary

From: [email-masked]
Date: Mon, 24 Jan 2005 23:11:24 -0600

Excellent comments.

Content transformation is VERY expensinve (especially immages).  An IMAP
server which does onboard content transformation will have many problems
with connection timeouts as people try to transform data.

The way I thought we were doing it (and this is probably what you meant)
is that CT is an optional addition to a Lemonade enabled server.  The
reason I say this is that there are quite a number of CT engines out
there commercially available.  We can spec an interface from the Client
to the IMAP server and from the IMAP server to the CT engine.

This way the CT engine can reside on a server (like an Oracle server or
IBM bladed machine), while still allowing maximum throughput for all
IMAP users who are doing regular accesses.

There are a few rules which we will need to put in place (Threading,
non-blocking client, request timeout, etc.) but these we will address
when we get closer to a working spec.

If the admin does not whish to add a CT server, he should be able to
setup the IMAP server to either a) Not advertise the CAPABILLITY, or b)
return a NO to MEDIACONVERSIONS requests.

Just my 2 cents :}

Corby Wilson

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Mark Crispin
> Sent: Monday, January 24, 2005 17:44 PM
> To: Wener Michael (Nokia-ES/Pittsburgh)
> Cc: [email-masked]
> Subject: Re: [lemonade] LEMONADE WG Media Conversion Summary
> 
> I would like to ask for a minor clarification, and offer a strawman.
> 
> Is it anticipated that media conversion would be a facility 
> of specialized IMAP servers?  Or, alternatively, is this 
> expected to become a more or less "mandatory to implement 
> extension" in general purpose servers?
> 
> I am asking because server-based media conversion may be a 
> severe burden to a general purpose server (as well as having 
> potential security implications), and any mandate to that 
> effect is potentially harmful. 
> I'm not necessarily opposed, but am sounding a note of caution.
> 
> On the other hand, an extension that is focused on 
> specialized servers, using a capability-driven mechanism, 
> seems to be a very obvious means of addressing the issue and 
> would have my enthusiastic support.
> 
> The assumption here is that this is a performance 
> optimization, and not a requirement for clients to work at 
> all.  I persist in my belief that all clients should work 
> with a base-level server without requiring any extension.
> 
> The capability mechanism need not be cumbersome; there could 
> be a general capability for media conversions, and then an 
> additional negotiation for the supported conversion 
> mechanism(s).  Although this likely adds an RTT, that may be 
> less costly in the overall scheme of things.
> 
> As a strawman, suppose the server offers MEDIACONVERSIONS as 
> an extension. 
> There could then be a command to query as to the available 
> conversions; or, alternatively, there could be a means by 
> which the client offers a list of its desired set of media 
> conversions and the server then reports the intersection 
> between these and what the server supports.
> 
> A shortcut that avoids the extra RTT is a form of FETCH that 
> lists the client-acceptable media conversions, and the server 
> can then choose one and perform it in the response.  One of 
> these client-specified conversions is "no conversion", which 
> would tell the server to send the data back unconverted 
> rather than barf.  How such a command is engineered would 
> largely depend upon client needs.
> 
> In spite of my note of caution above, I think that this is 
> potentially a very exciting and useful path for IMAP to take. 
>  It is one that was anticipated in IMAP from the onset.  So, 
> please treat my caution as a "do it right" rather than a 
> "don't do it."  :-)
> 
> -- Mark --
> 
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
> 
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade
> 

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Mon, 24 Jan 2005 21:16:39 -0800

> return a NO to MEDIACONVERSIONS requests.

I believe that a server which has a capability administratively disabled 
should not advertise that capability, rather than false state that it 
offers it and then return a NO.

A NO should only be returned in those cases where the end user can do 
something useful about the problem, e.g. create the name that does not 
exist, etc.  NO should not be used for a capability fault.

I deplore the practice of certain servers to return NO to FETCH, SEARCH, 
etc. commands on the grounds of "not implemented".  It is becoming 
painfully clear that a revision of RFC 3501 must explicitly forbid such 
behavior.

-- Mark --