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

From: "Weingarten Jerry" <[email-masked]>
Date: Wed, 9 Feb 2005 15:00:22 +0200

Hi,

A few notes on this -

1.  This is very similar to what I suggested just prior to the SF
meeting and also to what Cyrus was suggesting by using the ANNOTATE as
the carrier for the information.  In essence, the server acquires the
client's capabilities (possibly by using CC/PP, UAProf, or any other
mechanism) and make suggestions for each message part of what formats
the body part could be retrieved in.  The client then decides how it
wants to retrieve the different body parts, based on these suggestions.
This gives some control to the server but is not as drastic as MMS
(where the server does everything without consulting the client).

2.  It is unclear to me what you, Corby, mean when you say "the client
advertise it's capabilities to the server at the beginning of a session"
is this being advertised as part of the IMAP LOGIN or could it be done
by using CC/PP or something similar?

jerry
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lyndon Nerenberg
Sent: Wednesday, February 09, 2005 2:50 AM
To: [email-masked]; [email-masked]
Subject: RE: [lemonade] LEMONADE WG Media Conversion Summary - Update

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

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

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

_______________________________________________
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

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 09 Feb 2005 11:16:42 -0500

Hi Weingarten,

> by using CC/PP or something similar?

RFC2971 (IMAP ID extension) could be used by the client to advertise 
features to the server.

-- 
Cyrus Daboo