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

From: Eric Burger <[email-masked]>
Date: Mon, 29 Nov 2004 10:31:50 -0500

Sorry, but the conversion

   application/pdf -> audio/basic

makes sense.  We call it "Text-to-Speech".  Mail readers will render the pdf
as Text (not as Portable Document Format, but as the text rendered by the
PDF) and then read it.

Schematically, the server does:

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

Of course, Greg would like us to do

   application/pdf -> audio/g723

:)

What's the point of this?  One cannot make an algorithmic or protocol
mandate of what conversions make sense.  Conversions that don't seem to make
sense today may make sense tomorrow.

For example, consider:

   video/h263 -> text/plain

It turns out that the video can be a video of ASL, which gets translated
into text.  Sensible translation.  Of course, this brings up my favorite
topic, Message Context.  For example, the thing to be translated might not
be the signing, but lip reading :)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 24, 2004 6:47 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [lemonade] Channel updates for content conversion
> 
> 
> > -----Original Message-----
> > From: ext Lyndon Nerenberg [mailto:[email-masked]]
> > Sent: Tuesday, November 23, 2004 11:08 PM
> ...
> > --On 2004-11-23 9:24 AM -0600 [email-masked] wrote:
> > 
> > > How do you communicate that a conversion between top level
> > > media types is permitted? For example from pdf to plain
> > > text.
> > 
> > Advertise text/plain as a target conversion type.
> 
> I think of conversion as a function with a Domain and Range.
> CHANNELCONVERSIONS returns the Range. You seem to be assuming
> the Domain to be the universe of all content types, which is 
> reasonable. How do I know what the mapping is? For example 
> the following conversion makes no sense:
> 
> Convert(application/pdf) = audio/basic
> 
> Mike
> 
> _______________________________________________
> 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: Nathaniel Borenstein <[email-masked]>
Date: Mon, 29 Nov 2004 11:53:26 -0500

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

>    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