Subject: [lemonade] LEMONADE WG Media Conversion Summary

From: [email-masked]
Date: Mon, 24 Jan 2005 15:36:47 -0600

As per the chairs request below is my summary of the discussion 
to date ...

---------------------------
Abstract

  The problem of how to allow a client agent to gain access to media 
  conversion capability on an IMAP server has several potential 
  variations. This document outlines the issues as discussed within the
  LEMONADE working group.

1. Introduction and Overview

  In general, a client may be interested in receiving a MIME body part
  in streaming or non-streaming form. The case for retrieving a converted
  MIME body part in streaming form will be described in the WG profile 
  document [PROFILE]. Therefore streaming mode will not be referred to in
  the remainder of this document. This document deals strictly with the 
  case for non-streaming retrieval.

  The basic problem that needs to be solved is that the client must be 
  able to discover what it can convert, what it can convert it to and 
  while discovering this information it can not be flooded with large 
  amounts of superfluous information.

  Furthermore, once the client is informed of the server capabilities it
  must be able to effectively retrieve the body part in the converted 
  form.

  An effective way to describe the problem is as the server providing a
  conversion function with one set of content types (Domain) mapping to	
  another set of content types (Range). This mapping can potentially 
  be very verbose to communicate. This potential verbosity must be 
  mitigated.

2. Client Agent Capabilities

  A client is assumed to have sufficient intelligence to allow it
  to perform the following functions:

    1) The ability to probe the IMAP server to  discover what conversion
       capabilities the server has.

    2) The ability to make an intelligent choice regarding the target 
       conversion. If the client software can not make a automatic choice
       it is recognized the client can pass the decision on to the user,
       but this must be deferred to as a last option.

    3) The ability to retrieve the converted body part to the client as 
       it would retrieve a non-converted body part.
 
  Based on these premises the option to allow the server to 
  transparently perform conversions has been discarded within the 
  working group. Even if the conversion were based on a priori knowledge,
  or out-of-band client capability discovery, the client must be 
  involved in making the choice to convert and retrieve the target body
  part. This avoids the server having to rewrite a message into a new 
  MIME structure.

3. IMAP Server Capabilities

  A server has the ability to change what it can convert at any time.
  The server may also have a potentially large set of conversion
  capabilities. 

  Given these two facts, a client must be able to both discover the
  servers capabilities dynamically, and limit the amount of server 
  capability communicated to the client to only that which the client is
  interested in at the moment.

  A server may still have a form of out-of-band client capability 
  discovery. This may be used to allow the server to discover additional
  client parametric capabilities. An example of this would be the server
  finding out parameters it may use to convert image formats.

4. Client Discovery

  It is important that an efficient protocol for communicating the server
  capabilities be devised. The following options have been discussed in
  the WG:

    1) CONNEG style (RFC2703). This was discounted as a possibility 
       because of it's complexity. This is a set intersection approach
       which is not needed because the client ultimately has a user it
       can ask to resolve an ambiguity of choice.

    2) Client tells the server what Range it can accept. Server tells the
       client the subset of these that it can convert to. This again is
       another version of the intersection approach. It does allow for 
       a reduction of information being sent to the client.

       The problem is that if done strictly it results in an ambiguous 
       situation for the client. The client never knows directly what 
       the mapping is. It does know what item in the Range it may request
       , but it does not know what item in the Domain this is legal for.

    3) Client uses a form of Capabilities discovery by just asking the 
       server what it supports for a particular item in the Domain of 
       content types. The server responds with the entire Range it 
       supports for that specific item.

       This approach has the advantage of being very dynamic, intuitive 
       and direct. The disadvantage is that the client may receive Range 
       items which it does not care about.

    4) Server explicitly declares it's conversion capability in a 
       CAPABILITY response. This has two serious drawbacks: one, it 
       may make for a very cumbersome CAPABILITies string, and two, the
       client gets information it may not be interested in.

5. Client Retrieval

  Once the client has decided that it wants to convert a specific MIME 
  body part, and it has discovered that the server supports the desired
  conversion, it must retrieve the converted bytes.

  These bytes should be retrievable much the same way a FETCH allows 
  the retrieval of an un-converted body part. Some form of partial 
  retrieval should be allowed as well. The partial retrieval is useful
  in the same scenarios it would be useful during a normal FETCH.

  Conversion occurs on the IMAP server as the client requests it.

6. Bandwidth Optimization

  It has been observed that a form of bandwidth optimization may
  be achievable by using the same mechanism used in conversion to 
  retrieve MIME body parts in a compressed form.

  An optimal approach would be to allow the following functionality:
  
    1) The client may request a conversion retrieval in a compressed
       format.

    2) The server would support NULL conversions for all MIME types
       in the Domain. The client would then be able to retrieve an 
       unconverted MIME body part in compressed form by requesting
       a NULL conversion.

7. Normative References

   [PROFILE]   Maes, S. H., A. Melnikov,"Lemonade Profile", 
	       draft-ietf-lemonade-profile-XX , 2005.

8. Author

   Michael J. Wener
   Nokia, Inc.
   Phone: (906) 202-0538
   EMail: [email-masked]

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 24 Jan 2005 14:43:53 -0800 (Pacific Standard Time)

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.