Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-convert-13.txt

From: Dan Karp <[email-masked]>
Date: Tue, 18 Dec 2007 13:00:10 -0800 (PST)

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Enhancements to Internet email to
> Support Diverse Service Environments Working Group of the IETF.
> 
> 	Title		: IMAP CONVERT extension

I know that this will sound like a broken record, but *please* remove the dependency on METADATA from the CONVERT draft.  No other Lemonade draft requires METADATA.   Even a slimmed-down server-level-only METADATA is an extension that's way too much work for the benefit, and this CONVERT draft depends on the old non-slimmed-down METADATA.  And the syntax required to do CONVERT discovery via METADATA is baroque, to put it mildly.

I understand that there's a push to get this out the door.  But METADATA is still unpublished (for good reason) and the CONVERT discovery mechanism is just plain bad.  We're going to be stuck with Lemonade for some time, and it's worthwhile to try to make it not suck.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Tue, 18 Dec 2007 22:59:10 +0000

On Tue Dec 18 21:00:10 2007, Dan Karp wrote:
> I know that this will sound like a broken record, but *please*  
> remove the dependency on METADATA from the CONVERT draft.  No other  
> Lemonade draft requires METADATA.   Even a slimmed-down  
> server-level-only METADATA is an extension that's way too much work  
> for the benefit, and this CONVERT draft depends on the old  
> non-slimmed-down METADATA.  And the syntax required to do CONVERT  
> discovery via METADATA is baroque, to put it mildly.
> 
> I understand that there's a push to get this out the door.  But  
> METADATA is still unpublished (for good reason) and the CONVERT  
> discovery mechanism is just plain bad.  We're going to be stuck  
> with Lemonade for some time, and it's worthwhile to try to make it  
> not suck.

I'm willing to acccept that CONVERT discovery is useful, and,  
moreover, that METADATA represents the best choice for doing so.

However, I'm also of the opinion that CONVERT discovery of this kind  
- ie, pre-meditated discovery - is not what clients what nor need in  
the common case, based on conversations with Philip Van Hoof, and  
others.

The problem is when considering data which the server has more  
knowledge of than the client, which, I feel, is actually the common  
case

Consider the following two fairly extreme cases:

1) The "PDF case". Imagine a PDF - or similar self-contained compound  
document format - which contains a single page. Is this page an  
image, or is it text? The client doesn't know, the server may be able  
to determine which basic media type is more suited.

2) The "Unknown case". Imagine a badly behaved MUA sends an email  
with an attachment typed as application/octet-stream, which is  
actually a simple JFIF. I appreciate that nobody present really  
believes that this could be the case, but it will no doubt come as a  
complete shock that this actually happens. The server may be able to  
determine this quickly and easily.

You can easily come up with more ordinary cases, such as whether an  
image is best encoded as image/jpeg or image/png, but you get the  
drift.

It seems to me that this is a case where the HTTP-like content  
negotiation mechanism is of more use than the discovery/request type.

In other words. a client might signal its capabilities for media  
types to the server once per session, and the server would then  
provide the body part in the "most acceptable" format it could via  
the NIL "default conversion".

If there's interest, I think I can design a zero-RTT mechanism for  
clients to specify their media capabilities to the server. I think  
this can be optimized using techniques similar to those in XEP-0115,  
too, although that will get more complex.

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: Ken Murchison <[email-masked]>
Date: Wed, 19 Dec 2007 08:59:32 -0500

> I understand that there's a push to get this out the door.  But METADATA is still unpublished (for good reason) and the CONVERT discovery mechanism is just plain bad.  We're going to be stuck with…

I have mixed feelings on this.  I certainly understand Dan's concern 
that dependency on METADATA adds unnecessary complexity in trying to 
implement CONVERT.  As someone that has already implemented 
ANNOTATEMORE, trying to upgrade this to METADATA has proven non-trivial, 
mainly because of its interaction with LIST-EXTENDED, which itself is 
non-trivial.

I also understand and support the reluctance to add another discovery 
mechanism, when we already have an extensible, although complex, one in 
place.

I'm intrigued by Dave's content negotiation proposal, and I'd like to 
see a strawman.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Peter Coates <[email-masked]>
Date: Wed, 19 Dec 2007 06:42:02 -0800

I agree with a lot of these points.  On the other hand, there needs to be
some sort of discovery mechanism.  What are the options?  Can the METADATA
section be made conditional in some way?  FWIW, we do not have metadata
implemented on our server because of its dependency on listext.  We do have
the old annotatemore form instead.

I have implemented CONVERT, including image conversion.  And I have included
the metadata for that... it is not that bad with the extra wildcarding.
OTOH, I have looked at what is implied with configuring plugins for
conversions, and the metadata gets pretty ugly.

I have no personal objections to loosing the metadata section.  If we do
that we will need documents describing what parameters are needed for the
various conversion types, and probably a set of capabilities:
CONVERT => text/<text-subtype> charset=<scharset> 
		-> text/<text-subtype> charset=<tcharset>

<text-subtype> is plain or html
<scharset> is a range of charsets as listed in the draft
<tcharset> is utf-8

Required parameter: charset. Permitted parameter:
unknown-character-replacement

CONVERT=IMAGE => image/xxx -> image/yyy 
Parameters x-size, y-size, color-depth, greyscale (or something like that)

And so on.  And these would have to be well defined.

Peter

Dan Karp wrote:

>I know that this will sound like a broken record, but *please* remove the
dependency on METADATA from the CONVERT draft.  No other Lemonade draft
requires METADATA.   Even a slimmed-down server-level-only METADATA is an
extension that's way too much work for the benefit, and this CONVERT draft
depends on the old non-slimmed-down METADATA.  And the syntax required to do
CONVERT discovery via METADATA is baroque, to put it mildly.
>
>I understand that there's a push to get this out the door.  But METADATA is
still unpublished (for good reason) and the CONVERT discovery mechanism is
just plain bad.  We're going to be stuck with Lemonade for some time, and
it's worthwhile to try to make it not suck.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Dec 2007 14:52:37 +0000

Peter Coates wrote:

>section be made conditional in some way?
>
Speaking as an individual: this would be Ok with me.

>FWIW, we do not have metadata implemented on our server because of its dependency on listext.
>
See my other message on METADATA. My proposal to split METADATA would 
address that.

>We do have the old annotatemore form instead.
>  
>

---

From: Dan Karp <[email-masked]>
Date: Wed, 19 Dec 2007 07:10:26 -0800 (PST)

> I agree with a lot of these points.  On the other hand, there needs to
> be some sort of discovery mechanism.  What are the options?

Well, you could have the client tell the server its capabilities and have
the server automatically do the conversion based on the client's stated
preferences.  Or you could have a simple CONVERT-specific command that
allows a client to query what a given MIME type or message part can be
converted to (and what parameters can be supplied to the conversion).

Either one is fine with me.  I just want something that solves the problem
at hand and doesn't try to solve problems we don't have yet.  Because when
people try to generalize from one data point, that generalization's
almost guaranteed to be wrong....

---

From: Dave Cridland <[email-masked]>
Date: Wed, 19 Dec 2007 15:47:27 +0000

On Wed Dec 19 13:59:32 2007, Ken Murchison wrote:
> I also understand and support the reluctance to add another  
> discovery mechanism, when we already have an extensible, although  
> complex, one in place.
> 
> 
Indeed - I think the one we have is good for those cases where a  
client actually wants to get a specific conversion out of the server.  
The problem is the client is rarely in the best position to make a  
judgement call on what the best conversion might be.

> I'm intrigued by Dave's content negotiation proposal, and I'd like  
> to see a strawman.

Okay. So, in my proposal, we'd do something like:

1) The client specifies a media capability list, something like  
HTTP's Accept header. We would need to say things like "I can do  
text/plain or text/html. Whichever, I can do UTF-8 or US-ASCII  
charsets, and I know about format=flowed and format=fixed for  
text/plain". And "I can do image/jpeg, image/png, and image/gif. My  
screen resolution is QVGA portrait, and my colour depth is 16".

A proposal for a syntax might be that:

a) We handle the charset and screen resolution by saying "text/*",  
for example.

b) We otherwise list types in order of preference. The server may  
choose to override preferences - for example, the client may have  
suggested that HTML is preferable to plain text, but the server may  
determine that the PDF it's converting contains little formatting.

This gets us something that would look like:

A01 MEDIACAPS ("TEXT" "HTML") ("TEXT" "PLAIN" "FORMAT" ("FLOWED"  
"FIXED")) ("TEXT" "*" "CHARSET" ("UTF-8" "US-ASCII")) ("IMAGE"  
("JPEG" "PNG" "GIF") "PIX-X" "240" "PIX-Y" "320")

I've chosen a fairly complex, but hopefully concise, syntax here.

The client is saying (each parenthesized list converted to a  
sentence): "I do text/html. I will also do text/plain, preferably  
with format=flowed, but I can handle format=fixed too. For all text  
media types I do, I can handle a charset of either UTF-8 or US-ASCII.  
I can handle image/jpge, image/png, and, least preferred, image/gif,  
and my ideal resolution is 240x320." I couldn't immediately spot  
anything for colour depth, but you get the idea.

In ABNF, this looks like:

mediacaps-cmd = "MEDIACAPS" 1*(SP mediacap)
mediacap = "(" media-type SP media-subtype *( SP media-param SP  
media-param-values ) ")"
media-type = astring
media-subtype = DQUOTE "*" DQUOTE / astring / "(" astring *( SP  
astring ) ")"
;; "*" means all subtypes for the type mentioned in the command.
;; Otherwise, either the specific subtype or a list of them.
media-param = astring
media-param-values = astring / "(" astring *(SP astring) ")"
;; Either a single acceptable value or a list of acceptable values.

The command can't ever return NO. Even if the server hasn't a clue  
about any of the media types mentioned, returning NO doesn't make  
sense - the client is hardly likely to retry with a different screen  
size. :-)

We can make this more complicated by allowing a NO tagged response to  
MEDIACAPS, and allowing the argument to mediacaps to also be a hash  
used to identify the mediacaps in shorthand, so you'd get an exchange  
like:

C: A01 MEDIACAPS "1234567890123456"
S: A01 NO Unknown device
C: A02 MEDIACAPS (...)
S: A02 OK

(This form is subject to a potential preimage poisoning attack, but  
MD5 is sufficient to protect against this for the foreseeable future).

Both these look as if they're adding round-trips to session startup,  
but pipelining these commands is entirely practical. I'd imagine  
MEDIACAPS would be pipelined typically with ENABLE, and the second  
MEDIACAPS (in the second form) would be pipelinable with the first  
SELECT.

2) The client then uses the default conversion for all CONVERTs,  
unless it wants to do something specific - in which case it has to  
use the METADATA discovery.

Dave.

---

From: Mark Crispin <[email-masked]>
Date: Wed, 19 Dec 2007 08:05:37 -0800

On Wed, 19 Dec 2007, Ken Murchison wrote:
> I have mixed feelings on this.  I certainly understand Dan's concern that 
> dependency on METADATA adds unnecessary complexity in trying to implement 
> CONVERT.  As someone that has already implemented ANNOTATEMORE, trying to 
> upgrade this to METADATA has proven non-trivial, mainly because of its 
> interaction with LIST-EXTENDED, which itself is non-trivial.

When I read text such as the above I get a very nervous feeling about the 
entire Lemonade effort.

-- Mark --

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

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 19 Dec 2007 11:42:42 -0500

Hi Dave,

--On December 19, 2007 3:47:27 PM +0000 Dave Cridland <[email-masked]> 
wrote:

> Both these look as if they're adding round-trips to session startup, but
> pipelining these commands is entirely practical. I'd imagine MEDIACAPS
> would be pipelined typically with ENABLE, and the second MEDIACAPS (in
> the second form) would be pipelinable with the first SELECT.

So MEDIACAPS is just another example of where an extension does its own 
thing to push client info to the server. METADATA was meant to solve the 
other problem of extensions wanting to push information from the server to 
the client.

In spite of what Dan said in another message in this thread about trying to 
generalize leading to over engineering, I believe we need to generalize for 
this case.

So lets not invent another command specific to CONVERT - namely MEDIACAPS. 
Lets just figure out a way to do it with ENABLE. Then ENABLE can become the 
generic "client tells the server what it wants" extension that can be 
reused by other extensions.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Dec 2007 16:53:42 +0000

Mark Crispin wrote:

>> ANNOTATEMORE, trying to upgrade this to METADATA has proven 
>> non-trivial, mainly because of its interaction with LIST-EXTENDED, 
>> which itself is non-trivial.
>
> When I read text such as the above I get a very nervous feeling about 
> the entire Lemonade effort.

Mark, why would you say that?

The WG has started a long delayed discussion about things that needs to 
be added in Profile Bis versa things that should be removed. If the 
outcome of this discussion, for example, is that METADATA needs to be 
removed or split, then so be it. This tells absolutely nothing about the 
direction where this effort is going.

Regards,
Alexey

---

From: Curtis King <[email-masked]>
Date: Wed, 19 Dec 2007 11:38:49 -0700

On 19-Dec-07, at 9:42 AM, Cyrus Daboo wrote:

> So lets not invent another command specific to CONVERT - namely  
> MEDIACAPS. Lets just figure out a way to do it with ENABLE. Then  
> ENABLE can become the generic "client tells the server what it  
> wants" extension that can be reused by other extensions.

I like the idea. Do you have a strawman in mind?

ck

---

From: Mark Crispin <[email-masked]>
Date: Wed, 19 Dec 2007 10:41:19 -0800 (PST)

> Mark, why would you say that?

Multiple interlocking interdependecies frighten me.  So does the inclusion 
of facilities that are not absolutely necessary for mobile devices ("nice 
to have" is not the same).

These should frighten you too.

Lemonade really needed a mini-IMAP.  It did maxi-IMAP instead.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Dec 2007 19:02:36 +0000

Mark Crispin wrote:

> Multiple interlocking interdependecies frighten me.  So does the 
> inclusion of facilities that are not absolutely necessary for mobile 
> devices ("nice to have" is not the same).
>

They frighten me too. But this concern needs to be balanced against the 
need to have (a) a list of available facilities that is usable by mobile 
devices and (b) it is better to reuse protocol pieces, if possible.

You've originally commented on something which is not a final product 
yet. You should let the WG decide on the final choice first (and of 
course you should provide your feedback on that choice before it becomes 
final).

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Dec 2007 19:15:48 +0000

> anything for colour depth, but you get the idea.

Whatever you do, make sure that is works for desktop clients, which 
might support hundreds of MIME types (via OS facilities) and might not 
be able to know in advance which conversion parameters are supported by 
which MIME types.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 19 Dec 2007 20:54:49 +0100

Alexey Melnikov writes:
> might support hundreds of MIME types (via OS facilities) and might 
> not be able to know in advance which conversion parameters are 
> supported by which MIME types.

Why is that even interesting? Why would a desktop client with support 
for hundres of mime types (and presumably lots of RAM, hard disk and 
bandwidth, and no limited battery) want to use CONVERT at all?

(Yeah, I know, I should be packing the suitcases.)

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Wed, 19 Dec 2007 11:58:29 -0800 (Pacific Standard Time)

On Wed, 19 Dec 2007, Alexey Melnikov wrote:
> They frighten me too. But this concern needs to be balanced against the need 
> to have (a) a list of available facilities that is usable by mobile devices 
> and (b) it is better to reuse protocol pieces, if possible.

These are desirable goals, but the overriding concern must be simplicity. 
It doesn't matter that a new feature is small, or that it is simple to 
implement in [your | my] server, or that it would make life much easier 
for a nice guy who's a client implementor.

If the proposal is not absolutely necessary to the goal, it should be 
rejected; furthermore, if the proposal creates a dependency on something 
that is not absolutely necessary to the goal, it should also be rejected.

> You've originally commented on something which is not a final product yet. 
> You should let the WG decide on the final choice first (and of course you 
> should provide your feedback on that choice before it becomes final).

"Please wait for us to finish our work before commenting" is subsequently 
replaced with "the time to complain about this was when we were doing our 
work, and it's entirely too late to say anything now" (or a injured "why 
didn't you say something earlier?").

-- Mark --

---

From: Dave Cridland <[email-masked]>
Date: Wed, 19 Dec 2007 20:09:50 +0000

On Wed Dec 19 19:54:49 2007, Arnt Gulbrandsen wrote:
> Alexey Melnikov writes:
>> Whatever you do, make sure that is works for desktop clients,  
>> which might support hundreds of MIME types (via OS facilities) and  
>> might not be able to know in advance which conversion parameters  
>> are supported by which MIME types.
> 
> Why is that even interesting? Why would a desktop client with  
> support for hundres of mime types (and presumably lots of RAM, hard  
> disk and bandwidth, and no limited battery) want to use CONVERT at  
> all?

Well, there's the laptop-on-a-train scenario that I often find myself  
in. Plenty of RAM, disk, and sometimes even mains power, but not a  
lot of bandwidth.

Dave.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 19 Dec 2007 21:32:03 +0100

> in. Plenty of RAM, disk, and sometimes even mains power, but not a  

In which case I presume the MUA would carefully specify e.g. only jpeg, 
not all of the dozens of image types for which the OS provides support, 
so as to avoid getting a 64-bits-per-pixel uncompressed image (16 bits 
R, G, B and alpha - I've seen worse) in a format the OS supports but 
the MUA doesn't know about.

Arnt