Subject: CALL FOR CONSENSUS (was RE: [lemonade] on MTI conversions)

From: "Burger, Eric" <[email-masked]>
Date: Tue, 11 Apr 2006 11:29:47 -0400

Just to bring this to closure (as chair):

We definitely need a mechanism for object transcoding.  That is in the
charter and required by the voice messaging and mobile markets.  Said
differently, the work group consensus is there is a need for such a
protocol mechanism.

When we looked at the "minimum set of transcoding facilities" in order
to prove interoperability, we ran in to the VPIM problem squared.  For
review, the VPIM problem was that just about all interesting voice
codecs have some kind of IPR issues attached.  We ended up selecting
G.726, since the patents expired (!).  The problem is that G.726 is a
lousy codec (lots of MIPS for very little compression) and just about no
one implemented it.

The "squared" problem is that unlike VPIM, where everyone was building a
voice messaging system, LEMONADE is addressing disparate markets.  What
is interesting to the voice messaging folks, namely codec transcoding,
is of little interest to mobile folks, namely compressing/adapting (read
"downgrading") static content.  Moreover, compressing static content is
not of interest to the unified messaging folks.

Thus we looked for a transcoding operation that (1) would exercise the
transcoding mechanism, including the myriad transcoding parameters and
(2) would be generally useful to most or all of the target markets for
LEMONADE.  The solution we came up with is HTML to text.  This
transformation is generally useful for the unified messaging and mobile
markets.  It is not quite as useful for the voice messaging folks, but
it is simple enough to implement that it should not be a burden.

SPEAK NOW OR FOREVER HOLD YOUR PEACE: If you DISAGREE with this
position, respond to the list by 29 April 2006 with:
	(1) Your Objection
	(2) Justification for the Objection
	(3) Concrete proposal that meets the constraints.

Thanks.

-----Original Message-----
From: Ned Freed [mailto:[email-masked]] 
Sent: Saturday, March 25, 2006 6:30 PM
To: Keith Moore
Cc: Enhancements to Internet email to support diverse service
enivronments; Ned Freed
Subject: Re: [lemonade] on MTI conversions

> yes, but the point is that demonstrating interoperability is a
separate
> issue from MTI.

That depends on what sort of interoperability you're talking about.
Let's
please remember that this is the LEMONADE group, with some fairly
specific
goals for support of some fairly specific sorts of clients. The
conversion
facility isn't being developed because server-side conversion is
something we
all lust after, but rather because specific sorts of conversions are
needed by
some limited-capability clients.

Having said that, I think there's a conundrum lurking in all this, which
is
that for various reasons (IPR concerns being the most obvious) it may
not be
possible to specify the full set of MTI conversions a LEMONADE client
actually
needs. As I pointed out at the meeting, this gets very close to the same
set of
issues that had VPIM all wrapped around the axle for some time.

To put this another way, I would be willing to accept a toy MTI
conversion
despite my serious misgivings if it can be shown that the set of
conversions
generally useful to a LEMONADE client and which we are able to mandate
in an
IETF specification is empty. But I don't think that's the case: The
obvious
counterexample is the HTML to text the WG settled on.

> the purpose of demonstrating interoperability of a feature is to
> validate the specification - if two implementations of the same spec
> interoperate, this provides a sanity check of the spec.

But this begs the question of what should be in the specification to
meet our
WG requirements.

> of course if other profiles want to define other MTI conversions
before
> compliance can be claimed with those profiles, that's fine. but I got
> the strong impression that a lot of time was being wasted in the
meeting
> trying to figure out which marginally useful conversion all Lemonade
> servers have to implement for no other purpose than to satisfy a
> misunderstanding of IESG MTI criteria.

I believe this impression is not only incorrect, it is actually
backwards. The
slide initially showed a fairly significant list of MTI conversions. It
was
argued that some aren't needed by all clients and others are encumbered
in
various ways. This brought the list down to HTML to text, but with the
caveat
that the others will probably still be mandated by some OMA spec or
other. It
was then argued that the one remaining isn't generally useful, but I
didn't see
a lot of people buying into the argument. The need for one MTI was only
raised
as an afterthought.

				Ned

_______________________________________________
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: Randall Gellens <[email-masked]>
Date: Tue, 11 Apr 2006 14:15:09 -0700

At 11:29 AM -0400 4/11/06, Eric Burger wrote:

>  What
>  is of little interest to mobile folks

Just as an aside, I'm not sure this is the case.  I can imagine that 
codec transcoding could be helpful to mobile email clients on 
handsets.  This is strictly a parenthetical observation -- I am not 
disagreeing with your email.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There's nothing wrong with me.  Maybe there's something wrong with
the universe.       --'Dr. Beverly Crusher' in ST:TNG _Remember Me_.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 11 Apr 2006 23:20:32 +0100

> not of interest to the unified messaging folks.
I'm not entirely sure that's true. Mobile folk have limited sound 
codecs available, as Randy points out, and desktop folk on 
constrained bandwidth might want to use different codecs for content 
preview.

> it is simple enough to implement that it should not be a burden.
I'm far from convinced that HTML to text is actually as useful as 
people apparently think it is. The only messages I find that don't 
come with a useful multipart/alternative are spam, anyway. (Perhaps 
I'm lucky). This looks to me like finding a transformation for the 
sake of it.

As an alternative, might I suggest character set transformations for 
text/plain? Server support for character sets can be - and often are 
- much wider than client support, especially for some of the more 
obscure character sets, such as TIS620 (Thai, still not shipped in 
Java, apparently) as an example. We could pick a selection of 
character sets as sources, and transform them to UTF-8.

In practise, I'd imagine most implementations would end up using 
iconv or similar, and therefore support a much wider set than the MTI 
set.

(The transformation I'd most want to use would be JFIF quality and 
resolution changes, however, which are much more interesting.)

> position, respond to the list by 29 April 2006 with:

text/html -> text/plain is mostly pointless.

> 	(2) Justification for the Objection

HTML has good support, and the majority of HTML messages have 
text/plain alternates which are as the author's system intended.

> 	(3) Concrete proposal that meets the constraints.
Character set conversion for text/plain parts from various character 
sets (iso-8859-*, various others) to UTF-8. This is very simple to 
implement on most (all?) platforms if we choose the source character 
sets carefully, and should be useful on most targets platforms.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 Apr 2006 15:51:18 -0700 (PDT)

> I'm lucky).

That's exactly what you are: Lucky. I get legitimate HTML-only messages all the
time, enough to account for a significant percentage of my mail. And they from
a huge variety of sources. I also get a lot of multipart/alternatives (some
spam, quite a few not) where the text/plain part basically says "if you are
reading this your client is a piece of crap". A specific example of this last
sort of behavior is the Apple e-newsletter I regularly receive.

Like it or not, a lot of people now think it is perfectly OK to send HTML-only
email. And this number seems to be steadily increasing, and I doubt anything we
say or do is going to have the slightest impact.

> This looks to me like finding a transformation for the
> sake of it.

I disagree.

> character sets as sources, and transform them to UTF-8.

Interesting idea. Transformation to utf-8 on the server would be useful
in quite a few cases.

I would have no objection to adding or even switching to this. But I still
think the objections to HTML->text are totally misplaced.

> resolution changes, however, which are much more interesting.)

Agreed, but past experience getting consensus on this sort of thing
has not been good.

> text/html -> text/plain is mostly pointless.

I use it many time every day, so I hardly find it to be pointless.

> text/plain alternates which are as the author's system intended.

Not in my world, they don't. Unless by "intent" you mean the author didn't
bother to provide a usable plain text equivalent but used a structure that only
makes sense when one is provided.

				Ned

---

From: Mark Crispin <[email-masked]>
Date: Tue, 11 Apr 2006 16:08:18 -0700 (Pacific Daylight Time)

On Tue, 11 Apr 2006, Ned Freed wrote:
> I also get a lot of multipart/alternatives (some spam, quite a few not) 
> where the text/plain part basically says "if you are reading this your 
> client is a piece of crap". A specific example of this last sort of 
> behavior is the Apple e-newsletter I regularly receive.

I get that from a merchant that I used to deal with.  Not long ago, the 
merchant asked me why they lost my business.  I told them.

They are actually looking into getting it fixed.

> Like it or not, a lot of people now think it is perfectly OK to send 
> HTML-only email. And this number seems to be steadily increasing, and I 
> doubt anything we say or do is going to have the slightest impact.

In many cases, they don't know any better; it's the crappy software that 
they were sold.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Tue, 11 Apr 2006 23:45:37 -0400

At 23:20 +0100 on 04/11/2006, Dave Cridland wrote about Re: CALL FOR 

>sets carefully, and should be useful on most targets platforms.

One caveat for the ISO-8859-1 -> UTF-8 transformation - You need a 
sanity check for x80-x9f codepoints or just assume that the Charset 
is a lie and act as if it were Windows-1252/CP-1252. This works 
except if the message is coming from a Macintosh Client where there 
is a non-Windows compatible mapping of the ISO-8859-1 x80-x9f 
codepoints created by the MacRoman -> ISO-8859-1 transformation as 
well as the inaccurate ISO-8859-1 -> UFT-8 transformations for the 
few glyphs that exist in MacRoman but not ISO-8859-1 [the fractions 
and 2 or 3 other glyphs] where the MacRoman -> ISO-8859-1 transforms 
use ISO codepoint slots in the xa0-xff range for glyphs that are in 
MacRoman but neither Windows-1252 nor ISO-8859-1.