Subject: Re: [lemonade] WGCL Convert-05

From: Eric Burger <[email-masked]>
Date: Tue, 16 Jan 2007 02:49:45 -0800 (PST)

It is more than, "The OMA asked for it." Media conversion, WITHOUT DOWNLOAD, is generally useful for devices of limited capability.  That includes unified messaging systems that might just have tons of bandwidth but no possibility of "helper applications" to convert various formats.

So, the need to do conversion WITHOUT DOWNLOAD is very much in charter.  That said, the proposed mechanism may or may not be acceptable to us.  If it is not acceptable, AS A METHOD OF DOING CONVERSION WITHOUT DOWNLOAD, then say so.  If it is, say so.  If you don't care about conversions, abstain.

----- Original Message ----
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Sent: Monday, January 15, 2007 2:46:35 PM
Subject: Re: [lemonade] WGCL Convert-05

On Mon, 15 Jan 2007, Arnt Gulbrandsen wrote:
>> This also begs the question: why should such a concept exist in IMAP at 
>> all?
> Wasn't the answer to that question «OMA demand»?

And why isn't "no" an acceptable answer?  As in "no, we refuse to give you 
inexact data; we insist upon giving you precise, exact data."?

> Arnt (who didn't dare check whether this thing is required by profile-bis)

:-)

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it now.

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 16 Jan 2007 13:04:24 +0100

Eric Burger writes:
> It is more than, "The OMA asked for it." Media conversion, WITHOUT 
> DOWNLOAD, is generally useful for devices of limited capability. That 
> includes unified messaging systems that might just have tons of 
> bandwidth but no possibility of "helper applications" to convert 
> various formats.
>
> So, the need to do conversion WITHOUT DOWNLOAD is very much in 
> charter. That said, the proposed mechanism may or may not be 
> acceptable to us. If it is not acceptable, AS A METHOD OF DOING 
> CONVERSION WITHOUT DOWNLOAD, then say so. If it is, say so. If you 
> don't care about conversions, abstain.

I feel that if we have to have conversion in the server, then this 
mechanism is approximately what we need. It's not obvious to me that we 
benefit from adding conversions in the server (it's the client's need, 
so server authors feel little pain), but I could be persuaded on that.

I'll add one more serious item to my list from yesterday, though: The 
MTI html to text conversion does not make me at all happy. (For those 
who haven't read it: It's HTML to text/plain with correct rendering of 
tables and partial character set conversion.) Rendering tables 
correctly in text/plain is hard work and seems 99.9% pointless to me. 
One big problem is that the server has to assume a monospace font, and 
those are threatened by extinction.

If we just want something that permits test suites to run convert, let's 
have html->text without tables. If we want something real, let's have 
something that's useful to a couple of real in-charter clients.

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Tue, 16 Jan 2007 12:35:41 +0000

On Tue Jan 16 12:04:24 2007, Arnt Gulbrandsen wrote:
> I'll add one more serious item to my list from yesterday, though: 
> The MTI html to text conversion does not make me at all happy.

I have to admit I thought I'd argued for limiting to text/plain 
charset conversion as an MTI. HTML support in clients is actually 
pretty good, in practise, since most clients have supported this for 
a while.

Image thumbnailing is a practical use of this technology if you want 
something useful for deployment, but charset conversion is both 
useful to clients and easy to test.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Ben Last" <[email-masked]>
Date: Tue, 16 Jan 2007 12:36:38 -0000

>From: Arnt Gulbrandsen [mailto:[email-masked]] 
MTI html to text
>conversion does not make me at all happy. (For those who haven't read
it: It's HTML to
>text/plain with correct rendering of tables and partial character set
conversion.) Rendering
>tables correctly in text/plain is hard work and seems 99.9% pointless
to me. 
>If we want something real, let's have something that's useful to a
couple of real
>in-charter clients.

Unfortunately, there are mobile platforms in which there is no usable
HTML renderer for emails: our client runs on one.  We've actually ended
up writing our own Q-n-D HTML to plain text converter because of the
increasing number of HTML-only emails that users receive.  Whilst we
don't do full/explicit/proper table conversion, we make a stab at it (as
Dave Cridland said, it's better to see something than nothing at all).
If there was a decent server HTML->text converter, we'd use that in
preference.

Regards
Ben

R&D Manager
EMCC Software Ltd

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 16 Jan 2007 13:50:25 +0100

Ben Last writes:
> HTML renderer for emails: our client runs on one. We've actually 
> ended up writing our own Q-n-D HTML to plain text converter because 
> of the increasing number of HTML-only emails that users receive. 
> Whilst we don't do full/explicit/proper table conversion, we make a 
> stab at it (as Dave Cridland said, it's better to see something than 
> nothing at all). If there was a decent server HTML->text converter, 
> we'd use that in preference.

Decent surely means something that's tailored to your screen width and 
font, which isn't what the convert document specifies.

(Btw, I agree that this kind of thing is a good thing. My MUA has done 
html->plain;f=f for years, and it's so relaxing. I just don't think 
it's appropriate to render HTML for display in the server.)

Arnt

---

From: "Ben Last" <[email-masked]>
Date: Tue, 16 Jan 2007 12:51:34 -0000

>Decent surely means something that's tailored to your screen width
>and font, which isn't what the convert document specifies.
Ah... good point, but plain unwrapped text is still better than nothing.

One could argue, though, that conversion on the server with no knowledge
of screen size, resolution and fonts is a problem for many types of
conversion.  For instance, it'd be very useful to have the server
down-size images that are too large for client display.

Regards
Ben

R&D Manager
EMCC Software Ltd

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 16 Jan 2007 14:04:57 +0100

> Ah... good point, but plain unwrapped text is still better than nothing.

Better than the code you already have?

> One could argue, though, that conversion on the server with no 
> knowledge of screen size, resolution and fonts is a problem for many 
> types of conversion. For instance, it'd be very useful to have the 
> server down-size images that are too large for client display.

Sure. In that case the draft does the right thing: the client asks for a 
conversion including downscaling to a specified size.

Arnt