Subject: RE: [lemonade] Channel updates for content conversion

From: "Weingarten Jerry" <[email-masked]>
Date: Wed, 1 Dec 2004 11:28:48 +0200

Hi all,

I am writing this as a summary of this thread just to verify that I
understand what has been discussed -

1.  The result of the discussions in Vancouver was that the group is
planning on addressing the questions of content adaptations in two
threads - one for an on-line streaming case and the other for
content-adpatation (CA) prior to downloading.  Lyndon took the action
item to try and update the Channel document to address the second
thread.  I am not sure who took the action to address the streaming case
and do not recall seeing anything on the mailing list to indicate that
such a document has been drafted.

2.  Lyndon started an email discussion on his proposal that (to my
understanding) proposed two commands - CHANNELCONVERSIONS - that allows
the IMAP Server to indicate the MIME types it supports and an extension
to the CHANNEL that allows a Client to request a CA on a file included
in a MIME structure.  

3.  The main points that I gathered from the discussion that ensued were
-
A.  That the request for Server capabilities should be changed to allow
the client to indicate the input format and have the server reply with
the list of possible resulting formats.

B.  That there may be a need to specify additional parameters (e.g.
resolution, frame rate, etc) of the conversion besides just the
requested result MIME type.

C.  The group does not support the suggestion to have the CA request
added to the FETCH command.

D.  There may be a need to allow the Client to indicate where the Server
should store the resultant file and that the result may be indicated by
an IMAPURL (thereby accessible by URLAUTH).

4.  The issues that remained unclear (again, this is just my
understanding) -
A.  Is the CA being done by the IMAP Server or by some other entity.
Not sure, why this should affect the protocol between the Client and the
Server, since this may just be happening on the back-end of the Server!
If the suggestion is that the Client is sending a URLAUTH to the
Transcoding Server and requesting the CA service directly from the TS
then we would need something on the order of the STI protocol being
specified by OMA!

B.  What are the list of additional parameters that need to be added to
specify the transformation requested.  This again leads me to suggest
that we study the STI documents from OMA (assuming that they are
Public).

Please correct me if I have gotten anything wrong or missed anything!

Yaacov (Jerry) Weingarten
Comverse - Standards 
phone: +972-3-645 2392
mobile: +972-52-854 2392
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Nathaniel Borenstein
Sent: Monday, November 29, 2004 6:53 PM
To: Eric Burger
Cc: [email-masked]; [email-masked]
Subject: Re: [lemonade] Channel updates for content conversion

On Nov 29, 2004, at 10:31 AM, Eric Burger wrote:

> Schematically, the server does:
>
>    application/pdf -> text/plain -> audio/basic
>
> Of course, Greg would like us to do
>
>    application/pdf -> audio/g723

Just to muddy the water a tad further... this is one of the few areas 
where the small number of top-level MIME types is more than a minor 
organizational device, because what you might really want to specify, 
in some contexts, is simply the conversion:

	application/pdf -> text/plain -> audio/*

where the audio subtype might best be left unspecified until the 
capabilities of a receiving client are known.

More ominously, in your more fanciful example:

>    video/h263 -> text/plain

it's actually far more complex than you make it sound.  If you're 
translating a video of someone "speaking" ASL, not only is there 
ambiguity between lip reading and sign reading, there's also the 
possibility of using the closed captioning.  Far worse, what if it's 
not ASL but some non-English sign language?  It's far from trivial even 
to know how to set the "charset" parameter after the translation, but 
you *do* have to worry about that whenever you're talking about 
"text/plain" as a target.  At some point, any software that does the 
voice-to-text conversion is going to have to be able to set the 
character set on its output, because it's going to be the component 
best able to tell the difference between spoken English and spoken 
Chinese.

<philosophical rant>
Back in the bad old days when lots of mail went through gateways to 
different email protocols, I liked to say that "no gateway ever 
improved a message that went through it."  The same is surely true of 
format translation.

To me, this suggests that format translation is a last resort, and 
always best delayed to the last possible moment.  The goal of LEMONADE, 
of course, is to optimize bandwidth usage for currently-expensive 
mobile connections, and format translation is certainly a plausible way 
to approach that goal.  It would be a shame, however, if in enabling 
such optimizations, we created legacy barriers to better solutions in a 
hypothetical future where mobile bandwidth is cheap.(**1**)  In short, 
we need to be sure there's always a way to turn all our "optimizations" 
off.
</rant>

We now return to our regularly-scheduled nitpicking.  -- Nathaniel

(**1**)  Circa 1980, the dedicated line in our CMU offices was upgraded 
from 1200 baud to 56K, and some people quickly took advantage of that 
enormous bandwidth to replace command line software with friendly 
interactive menus (ZOG).  A grumpy fellow grad student described this 
as "the most obscene waste of bandwidth I ever saw" but I was inspired 
to dump AI and theory in favor of research on human-computer 
interaction.

Circa 1990, I sent one of the first "interesting" MIME messages to the 
ietf-822 list, containing a 4-second audio clip of my voice, saying 
"Memory is cheap, bandwidth is cheaper!"   Even on that forward-looking 
mailing list, I got more than a few irate complaints about such a 
profligate waste of bandwidth (about 50K in one email!) and the 
"inefficiencies" it portended.

Circa 2005, we have LEMONADE.  I just hope we don't lock in too many 
assumptions about the duration of our current bandwidth limitations. -- 
Nathaniel

_______________________________________________
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: [email-masked]
Date: Wed, 1 Dec 2004 07:10:27 -0600

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Weingarten Jerry
> Sent: Wednesday, December 01, 2004 4:29 AM
...
> understand what has been discussed -

Good summary from my perspective. I have a couple comments.

> content-adpatation (CA) prior to downloading.  Lyndon took the action

Lyndon mentioned an inband scheme, which would skip the secondary
step of downloading. I think this is a good idea.

> 3.  The main points that I gathered from the discussion that 

Also, I raised the issue of partial fetches in the case of inband
retrieval.

Mike

---

From: Eric Burger <[email-masked]>
Date: Sun, 5 Dec 2004 16:31:35 -0500

I'm not sure I like this one:

> From: Weingarten Jerry [mailto:[email-masked]]
[snip]
> should store the resultant file and that the result may be 
> indicated by an IMAPURL (thereby accessible by URLAUTH).
[snip]

What do we mean by "where"?  Will that impose protocol support / negotiation
on the server's part?  What if "where" isn't writable by the server?  What
if "where" isn't there when the server needs it?  Sounds like a very
difficult problem to solve.