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

From: "Erev Ari" <[email-masked]>
Date: Tue, 25 Jan 2005 10:12:33 +0200

Hello,

I would like to relate to comments made by Mark and Corby.

Mark said:

> 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?

And Corby:

> 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.

I propose that the IMAP Conversion solution, is designed in such a way
that it *CAN* be
Implemented by an IMAP Proxy.

Note - I am not suggesting that this should be the *ONLY* implementation
choice. I only
suggest that the solution takes such an implementation into
consideration.

Although I agree upfront, that a Proxy solution has its own
complications, it also has many advantages, especially when maintaining
a very large
system with different "life cycles" of the IMAP/Messaging server, and
the media conversion requirements, 
which are usually related to a different set of aspects (such as
specific type of clients (hand-sets) and capabilities.

A solution involving an IMAP proxy that handles the media conversion
supports both comments from Marc and Corby:

1. It allows the use of "general purpose" IMAP servers at the back-end.
2. It off-loads the main server from the content transformation work.
(even if the actual media conversion is done by
    an external Content Transformation server that the IMAP server talks
to - it still puts a considerable burden on the 
    IMAP server to manage this interaction). This allows to cope with
scalability by adding proxies (to handle the expensive
    media conversion) rather than upgrading the back-end IMAP servers.

And I would like to add:

3. It allows a certain degree of flexibiliy to change/manage the
behavior of the "media conversion" facet of the "system" with 
    minimal effect on the IMAP server itself.

Ari

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

---

From: [email-masked]
Date: Tue, 25 Jan 2005 23:39:42 -0600

I agree COMPLETELY.

I don't like NO for this purpose and would rather see the CT server
advertised as a CAPABILTY.

Corby=

P.S.: Mark, if you support a rewrite of 3501 to fix NO, I'm all for it
:)=)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Mark Crispin
> Sent: Tuesday, January 25, 2005 00:17 AM
> To: Wilson Corby (Nokia-ES/Pittsburgh)
> Cc: Wener Michael (Nokia-ES/Pittsburgh); [email-masked]
> Subject: RE: [lemonade] LEMONADE WG Media Conversion Summary
> 
> On Mon, 24 Jan 2005 [email-masked] wrote:
> > 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.
> 
> 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 --
> 
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>