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

From: Dan Karp <[email-masked]>
Date: Wed, 19 Dec 2007 08:18:13 -0800 (PST)

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

Ah.  You see, here's where we differ.

*You* have an already-implemented extension that you think you can can
shoehorn discovery into.  *I* have a METADATA draft that I've got zero
intention of implementing because it's an utter pain in the ass.  If
you add discovery behavior into METADATA, I and every other wannabe-
Lemonade-compliant server implementor are stuck doing the rest of the
mailbox-level stuff, the LISTEXT integration, the shared/priv nightmare,
the value/size stuff, and handling writable annotations.

I DO NOT WANT TO DO THIS.

Lemonade should be the smallest set of IMAP extensions that solves the
problem we're trying to solve.  AND NO MORE.  METADATA falls on the
wrong side of that balance and thus needs to be excised from Lemonade.

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 19 Dec 2007 17:26:44 +0100

Dan Karp writes:
> METADATA falls on the wrong side of that balance and thus needs to be 
> excised from Lemonade.

I agree with the latter, but for somewhat different reasons. I don't 
think metadata is a good fit for the problem. I like Dave's suggestion 
rather better.

And since this is probably my last mail before 2008: Merry Chrismas, 
everyone, and a happy new year!

Arnt

---

From: Dan Karp <[email-masked]>
Date: Wed, 19 Dec 2007 08:32:14 -0800 (PST)

> > METADATA falls on the wrong side of that balance and thus needs to
> > be excised from Lemonade.
> 

I think I'd lean towards Dave's solution as the right one as well.

---

From: Curtis King <[email-masked]>
Date: Wed, 19 Dec 2007 10:28:36 -0700

> wrong side of that balance and thus needs to be excised from Lemonade.

+1

ck

---

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

+1.  Strongly.

>> wrong side of that balance and thus needs to be excised from Lemonade.

-- 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: Dave Cridland <[email-masked]>
Date: Wed, 19 Dec 2007 20:06:33 +0000

On Wed Dec 19 16:32:14 2007, Dan Karp wrote:
> > > I agree with the latter, but for somewhat different reasons. I   
> don't > think metadata is a good fit for the problem. I like Dave's  
>  suggestion
> > rather better.
> 

You're making it sound like it's an either/or case, and I think it's   
a "both".

There are two use-cases:

1) "Give me this part in a way that I probably understand it!"

2) "What can I turn this part into?"

The first is handled by default conversion, the missing bit has   
always been that we have no method for telling the server what we   
probably understand. This missing bit is what I've proposed.

The second is currently handled by METADATA based discovery, which   
seems reasonable, excepting the case where the part involved is   
application/octet-stream or otherwise mis-typed. A counter-proposal   
would, for me, need to address this case, as well as remaining   
capable of operating by type, rather than only on a specific part.

I suspect that mobile clients will generally only use (1), whereas  
desktop clients will use both.

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: Dan Karp <[email-masked]>
Date: Wed, 19 Dec 2007 12:16:44 -0800 (PST)

> capable of operating by type, rather than only on a specific part.

I'm not convinced that there's a real-world need for a solution to the
second use case.  Odds are that your desktop client can handle far more
MIME types than your server can convert.  I also think that solving the
second use case is not a Lemonade problem.  A solution that nails the
first use case should suffice.  But if you must have an alternate
solution, here's the one I sent out a little while back:

   CONVERSIONS <source> <target>

where <source> and <target> are partially or completely wildcardable.
For instance, for conversion info from GIF to JPEG (no untagged CONVERT
would be returned if no conversion was possible):

   C: a CONVERSIONS "image/gif" "image/jpeg"
   S: * CONVERT "image/gif" "image/jpeg" ("width" "height" "depth" "interlaced")
   S: a OK CONVERSIONS completed

For conversion info from GIF to anything:

   C: b CONVERSIONS "image/gif" *
   S: * CONVERT "image/gif" "image/jpeg" ("width" "height" "depth" "interlaced")
   S: * CONVERT "image/gif" "image/png" (...)
   S: ...
   S: b OK CONVERSIONS completed

For conversion of anything to JPEG:

   C: c CONVERSIONS * "image/jpeg"
   S: * CONVERT "image/gif" "image/jpeg" ("width" "height" "depth" "interlaced")
   S: * CONVERT "image/png" "image/jpeg" (...)
   S: ...
   S: c OK CONVERSIONS completed

For conversions from all image formats to all text formats (maybe via OCR?):

   C: d CONVERSIONS "image/*" "text/*"
   S: d OK CONVERSIONS completed