Subject: RE: [lemonade] Proposal for Content Adaptation

From: [email-masked]
Date: Mon, 3 Jan 2005 07:34:02 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Weingarten Jerry
Sent: Thursday, December 30, 2004 7:05 AM
...
> I would like to suggest a slight alternative to the CHANNEL 
> suggestion 

For clarity, would this be in lieu of the CHANNELCONVERSIONS 
command suggested earlier on the list?

Comments ...

 Sec 1.3  
"... it saves on queries from the Client to the Server as to 
what transformations are possible."

On the contrary this seems to increase the amount of traffic 
between the client and the server. The mapping information
for each body part is asked for each message. It is likely
that if a server supports application/pdf -> text/plain for
one message it will for all. So the client only needs to ask
the general question not the same question for each message.

Sec 1.5
This section is confusing. After issuing the CAFETCH we have
the following statements.

"Alternatively, the Client may choose to ignore the suggestions 
provided by the Server in the response to the CAFETCH and use 
the CHANNEL command to query the Server on what formats are 
available to transcode the original media format to."

Is this a second query? Of what form and why would a second 
query be needed?

"... the Client chooses to transcode a particular body part to 
a media format not originally suggested by the server ..."

Why would a client choose to do this?

Sec 4
Why add the complication of parsing another BODYSTRUCTURE?
A client will have already parsed a BODYSTRUCTURE from the 
FETCH command. Why not just use a simply parsed list that
uses the dotted naming convention for MIME parts.

Mike

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

---

From: "Weingarten Jerry" <[email-masked]>
Date: Tue, 4 Jan 2005 15:09:03 +0200

Hi,

I obviously did not present my suggestion very clearly.  I will try to
restate it and thereby attempt to answer the questions and comments that
Michael makes:

1.  The idea presented was  that the Client would issue a CAFETCH
instead of a FETCH BODYSTRUCTURE command and receive in reply all
information of the FETCH with the addition of extended information for
each body part that indicates a list of media formats that the Server
can make that body part available in.  The Client can then issue a
CHANNEL command to retrieve the parts in one of the suggested formats.
This use would preclude the need for the CHANNELCONVERSIONS command
usage.

2.  There is a possibility that none of the suggested conversions are
acceptable to the Client (who we are assuming is the final arbiter of
what conversion to perform) and in such a case, the Client could still
use the CHANNELCONVERSIONS command to interogate the Server for other
possibilities of conversion and then, based on the responses received
issue the appropriate CHANNEL command to perform the actual conversion.

Now in reply to the comments and questions:

>> For clarity, would this be in lieu of the CHANNELCONVERSIONS command
suggested earlier on the list?

Using scenario 1 above, yes it could save the use of this command.
However, I do not advocate getting rid of the flexibility of having the
command available for Clients that may opt, in special cases, to use
scenario 2.

>>  It is likely that if a server supports application/pdf -> text/plain
for one message it will for all. So the client only needs to ask the
general question not the same question for each message.

This comment makes a few assumptions that need to be clarified.  For
one, yes if the Server supports a certain conversion for one message it
should support it for all messages but it may be possible that for
different messages additional conversions may be suggested (e.g. if a
Powerpoint file is only a single slide it may be appropriate to suggest
an image conversion in addtion to a text conversion).  Second issue is
whether you are suggesting that the Client generate a database of the
Server capabilities in order to save the queries? Third assumption id
that the query is being made at the time of listing the contents of the
mailbox and not at retrieval of the message, which needs clarification.

>> This section is confusing. After issuing the CAFETCH we have the
following statements...

I hope my presentation (at the beginning of this message) clarified the
confusion.

>> Why add the complication of parsing another BODYSTRUCTURE? ...

Again, I hope that the presentation at the beginning of the message
clarified this.  In addition, I am willing to have this just be defined
as an extension of the FETCH command, however, my understanding was that
the group (and imapext group) was not  in favor of adding any new
features to the FETCH command and therefore I presented it as a "new"
command.

Thanx for the comments,
jerry

---

From: [email-masked]
Date: Mon, 10 Jan 2005 18:24:08 -0600

> From: ext Weingarten Jerry [mailto:[email-masked]]
> Sent: Tuesday, January 04, 2005 8:09 AM
...

Thanks for the clarification. It helped.

> issue the appropriate CHANNEL command to perform the actual 

I still don't understand why the server would return different 
conversion possibilities in each scenario. Why wouldn't the server 
just tell the client all possible scenarios once?

> should support it for all messages 

Yes, we agree. So communicating this information per message is 
redundant.

> but it may be possible that for
> an image conversion in addtion to a text conversion).  

No assumption on my part here. I agree there may be several elements
in the range of possible conversions. These multiple possibilities 
should be communicated to the client all at once when asked.

> Second issue is
> Server capabilities in order to save the queries? 

No, I'm not suggesting this. I'm suggesting that the client ask per
session not per message. This does not imply a database.

> Third assumption id

I'm not sure what you mean "needs clarification". Yes, I'm
suggesting that the client ask this at some time separate from
the time the client asks for each message BODYSTRUCTURE. I 
think this is reasonable. Clients do this type of thing all the 
time. For example, when the mailbox is first selected a client
may request all the body part MIME headers, then later request
the actual body part.

So I envision a scenario such as ...
Select
get supported conversions
get message meta-data
get message body parts as needed (possibly converted)

Mike