Subject: [lemonade] on MTI conversions

From: Keith Moore <[email-masked]>
Date: Wed, 22 Mar 2006 10:37:48 -0500

listening to the discussion on conversions, I question the need for an 
MTI conversion set.  since conversion is an optional feature, I don't 
see how failure to implement any particular conversion results in 
degraded interoperability of the protocol.

however I do see the need to demonstrate interoperability of the 
conversion feature so that it can advance along the standards track.  so 
for these purposes I would propose that there be an informal implementor 
agreement to implement two or three trivial conversions (that require 
parameters) for the purpose of interop testing.

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

---

From: Ned Freed <[email-masked]>
Date: Sat, 25 Mar 2006 07:43:05 -0800 (PST)

> degraded interoperability of the protocol.

It's an optional feature in general of course, but it remains to be seen
whether it it is going to be optional or not in the revised LEMONADE profile.
(There's also the issue as to how it relates to streaming, which since we don't
have a draft is kinda hard to pin down.)

> parameters) for the purpose of interop testing.

It's an interesting idea, but I'm far from convinced it would fly with the
IESG. Heck, I'm not completely convinced myself.

In any case, I think we need to first see how the profile situation plays
out before deciding to try such a thing.

				Ned

---

From: Dave Cridland <[email-masked]>
Date: Sat, 25 Mar 2006 21:38:48 +0000

> have a draft is kinda hard to pin down.)
If we make it mandatory in the Lemonade Profile, we can always add in 
MTI conversion at that point, specific to the Lemonade Profile. In 
fact, I'd have thought we would want to add in a set of MTI 
conversions if we bring it into the Profile, whatever it has already.

> IESG. Heck, I'm not completely convinced myself.
I have to admit I'm not entirely happy with the idea of an MTI being 
present purely to fix a process issue.

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: Sat, 25 Mar 2006 14:11:14 -0800 (PST)

> conversions if we bring it into the Profile, whatever it has already.

Keep in mind that even if this doesn't appear as part of the LEMONADE profile
the sense in the room was that a fairly significant set of converters are bould
to be part of OMA requirements in this area.

> present purely to fix a process issue.

First, adequate demonstrability of interoperability is hardly a mere "process
issue". And the record on interoperability in this space when only toy
placeholders are required is spotty at best. (If memory serves, this is more or
less what the GOSIP profile of X.400 called for, and that scheme never
interoperated worth spit on any system I ever saw.) 

Second, it is far from clear to me that a mandatory to implement conversion
serves no other purpose but to provide an interop guarantee.

				Ned

---

From: Dave Cridland <[email-masked]>
Date: Sat, 25 Mar 2006 22:36:27 +0000

On Sat Mar 25 22:11:14 2006, Ned Freed wrote:
>> > It's an optional feature in general of course, but it remains to 
>> be
>> > seen
Yes, true, there are multiple levels at which conversions could be 
mandated.

> placeholders are required is spotty at best.

The former of these statements I agree with, but only when, in this 
case, the conversion required is actually genuinely useful to mandate 
for reasons other than purely demonstrating interop - that would be 
an instance of the latter.

> serves no other purpose but to provide an interop guarantee.

I think we're in full agreement here - you, myself, and Keith.

My concern - and I have the possibly incorrect impression this is 
Keith's concern too - is that the discussion on MTI conversions in 
the WG meeting seemed purely related to getting one to pass some idea 
of interop testing, and not really to serve any other purpose.

Dave.

---

From: Keith Moore <[email-masked]>
Date: Sat, 25 Mar 2006 17:48:08 -0500

> First, adequate demonstrability of interoperability is hardly a mere 
> "process issue". 

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

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.

the purpose of MTI options is to ensure that two implementations that 
each conform to the spec will be able to interoperate even if they 
implement different sets of options.  without MTI one implementation 
could implement only option A, another could implement only option B, 
and they couldn't talk to one another.  for instance if a SMTP client 
only implemented BDAT and a server only implemented DATA, they couldn't 
exchange messages.

but for the case of conversion of body parts in IMAP, the MTI conversion 
option is already provided for in the base IMAP spec - it's the null 
conversion.  since all IMAP servers have to be able to provide body 
parts in their native form - without converting them - the basis for 
interoperability already exists.

if someone wants to be pedantic about it, define a conversion named 
"NULL", which would serve no other purpose than to be able to test the 
command parsing code.  but at least it would be easy to implement and 
hopefully noncontroversial.

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.

Keith

---

From: Ned Freed <[email-masked]>
Date: Sat, 25 Mar 2006 15:29:50 -0800 (PST)

> yes, but the point is that demonstrating interoperability is a separate

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.

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

> 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