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

From: [email-masked]
Date: Tue, 8 Feb 2005 08:33:14 -0600

I keep thinking it would be easier to invert the problem.
Since the client is the one with the limited capabilities, why not have
the client advertise it's capabilities to the server at the beginning of
a session.  This way it's the server's responsibility to remember the
clients' range.
The only problem here is that now the server determines the first-pass
best translation method.  This would mean that the client and server
would need to negotiate, but most likely first-pass would be accepted by
the client 95% of the time since the server is basing it's decision on
the list the client sent.
The MIME type range sent by the client could be sent in preference order
so the server choice would be deterministic.

Corby Wilson

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Weingarten Jerry
> Sent: Tuesday, February 08, 2005 03:35 AM
> To: Wener Michael (Nokia-ES/Pittsburgh); [email-masked]; 
> [email-masked]
> Subject: RE: [lemonade] LEMONADE WG Media Conversion Summary - Update
> 
> Hi,
> 
> I know that we have already had this discussion - but I would 
> like to see us supporting both of these options.  I do not 
> like the idea of having the client retaining the list of 
> possible conversions when what he is really interested in is 
> - "how do I fetch the body parts of the current message?"  
> The first option meand that either at the beginning of each 
> session the client is asking questions that may not be 
> relevant and remembering the list of conversions or that the 
> client retains this information across sessions, also not very savory.
> 
> jerry
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Monday, February 07, 2005 11:32 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [lemonade] LEMONADE WG Media Conversion Summary - Update
> 
> > -----Original Message-----
> > From: ext Cyrus Daboo [mailto:[email-masked]]
> > Sent: Monday, February 07, 2005 11:36 AM
> ...
> > --On February 6, 2005 7:50:12 PM -0600 
> [email-masked] wrote:
> > 
> > > 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:
> > 
> > I would like to suggest another set of options for this:
> > 
> > 1) ANNOTATEMORE can be used to 'advertise' the server's mapping 
> > capabilities in detail rather than forcing all of that into 
> CAPABILITY
> 
> > or a new command to discover the mappings.
> 
> I like this idea a lot.
> 
> > 
> > 2) The ANNOTATE extension allows annotations on a per-body 
> part basis,
> 
> > so ANNOTATE can be used by the server to advertise the 
> explicit set of
> 
> > mappings it can perform on each body part. Clients can then fetch 
> > those annotations at the same time as it fetches the 
> message envelope 
> > or bodystructure data, thus avoiding a roundtrip for the mapping 
> > discovery.
> 
> I don't like this approach. This suffers from the problem of 
> being redundant. It would seem very unlikely that a server 
> would advertise that it can convert X into Y for one message 
> and not another. So why have the client ask for each message, 
> when it can discover this via ANNOTATEMORE.
> 
> Mike
> 
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade
> ______________________________________________________________________
>   This email message has been scanned by PineApp Mail-Secure 
> and has been found clean.
> 
> 
> 
> 
> _______________________________________________
> 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: Lyndon Nerenberg <[email-masked]>
Date: Tue, 08 Feb 2005 16:49:55 -0800

--On 2005-2-8 8:33 AM -0600 [email-masked] wrote:

> Since the client is the one with the limited capabilities, why not
> have the client advertise it's capabilities to the server at the
> beginning of a session.  This way it's the server's responsibility to
> remember the clients' range.

I like this. (I've been wrestling with how to efficiently handle 
"resource discovery" of the transformation list in Channel when the 
server supports a large set of conversions, thus the delay for an 
updated draft). I think it's safe to assume that clients that require 
conversion will support a limited set of target media types. Let me run 
out a new draft based on this concept. I think it will address most of 
the concerns brought up at and since the Vancouver meeting.

Not related to this, someone mentioned that the set of transformations 
could change in the lifetime of an IMAP session, and that the protocol 
needs to handle these dynamic updates. I find it hard to believe that 
this would really be the case. Can anyone give some real world example 
of how and where this would be the case? And justify the added 
complexity in the client state machine to support this dynamic 
behaviour? (Yes, I'm against this. But I'm willing to be proved wrong.)

--lyndon