Subject: [lemonade] CONVERT

From: Philip Van Hoof <[email-masked]>
Date: Fri, 11 Jan 2008 15:32:45 +0100

o. In CONVERT's 13th draft:

   Instead of specifying the exact target MIME media type the client
   wants to convert to, the client MAY use a special marker NIL (also
   known as "default conversion") to request the server to pick a
   suitable target media type. This document doesn't describe how the
   server makes such a choice.  

	etc etc

  An E-mail client must prepare its mime part view so that it can show
  the content of what is being received efficiently. With a default MIME
  media type that will be used to convert to, this ain't possible.

  For example a thumbnail of a streaming video, converting to a
  progressive JPEG, etc.

  Therefore are all concepts of the server providing some sort of a
  default conversion target not useful for an E-mail client. 

o. The concept of having a registry of possible conversions using
   GETMETADATA can't support conversions of one of the most common MIME
   part types: application/octet-stream.

   What the client developer really wants is once he received and parsed
   the bodystructure and figured that it can't use a MIME part, to ask
   the IMAP server what it can convert "that specific" MIME part to.

   For example in case the bodystructure said: application/octet-stream,
   the IMAP server could tell the E-mail client: but I can convert it to
   a resized flash animation for you, or a video/mpeg, ...

   This ain't possible with GETMETADATA, as GETMETADATA can't support
   application/octet-stream, because it can't tell the client what "that
   specific" MIME part is about. So the client has no clue either.

   I fear that a registry of possible conversions, like GETMETADATA, is
   therefore wrong.

   I think the list of possible conversions should be queryable per
   specific MIME part.

- The client can then "see" a application/octet-stream and ask the IMAP
  server whether it can offer the data in a better format

- The server can at that point perform a slow operation to figure out
  the content of that MIME part, to compute its list of conversion
  formats, and return it to the client.

  I know IMAP server developers think this is a burden for them to
  implement, but the client really has no clue whatsoever what the data
  is about. So it can't know what it could possibly ask for when
  requesting a CONVERT.

  (note that this procedure does not need to be fast, if the imap server
  has to scan the header of the data and it consumes time doing that,
  that's fine, really)

- The client can now prepare itself for the retrieval of this data in a
  for itself useful formatting

- The client can now request the CONVERT, and keep its viewer/retriever
  ready for the data

- The IMAP server sends the converted data to the client, the client's
  viewer/retriever shows it to the user

This is not possible with GETMETADATA:

- Only known MIME parts can be supported. The application/octet-data
  MIME part can't be supported (this just doesn't fit in the concept of
  a registry of possible conversions, as each application/octet-data can
  be different. And the client doesn't know anything whatsoever about
  the format of that data, at that point).

  Note that application/octet-data is the most likely format that will
  have to be converted. It's precisely for that kind of MIME parts that
  convert is interesting.

- Else NIL must be used which means that the client has no idea
  whatsoever that will be sent 

  -> It must parse the BODYPARTSTRUCTURE CONVERT response and
     immediately after that must it be prepared for that:

     - What if it nonetheless can't support that default format?! Must
       it receive useless data and waste bandwidth now?!

     - What if the CPU of the device just isn't fast enough to prepare a
       mime part viewer quickly enough to start showing the now
       converted data, that is already being received, to the user?

Short version, CONVERT's draft 13 is not implementable for a client in a
convenient way. The methodology of a registry of possible conversions,
doesn't really work ... 

The idea of a default conversion absolutely doesn't work for the client.

It's a conversion that goes like: 

C: I have no clue, give me something ... something whatever

S: I'm going to send you some stuff, a millisecond before I send you the
   data I'll tell you how it'll look, but I wont tell you what I will
   send you until that millisecond before I start. If that data doesn't
   work for you, all you can do is cut the connection or politely waste
   bandwidth until I'm finished sending.

Doesn't make sense imho ...

In stead of 

C: I have no clue, give me A CLUE

S: A clue: I can do A B and C

C: Alright, so give me B

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be

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

---

From: Philip Van Hoof <[email-masked]>
Date: Fri, 11 Jan 2008 15:39:50 +0100

> S: A clue: I can do A B and C

Note that GETMETADATA would be useful to save a roundtrip asking for the
clue in case the client actually has a clue.

But the only way it can have a clue, is by recognising a known MIME part
that was registered in the GETMETADATA registry.

Which wont be the case for application/octet-stream, for example.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 Jan 2008 09:19:14 +0000

Hi Philip,

>  default conversion target not useful for an E-mail client.
I disagree with this statement: the client can use BODYPARTSTRUCTURE to 
determine the target MIME type:

         C: e001 CONVERT 2 (NIL) (BODYPARTSTRUCTURE[2])
         S: * 2 CONVERTED (TAG "e001") (BODYPARTSTRUCTURE[2] ("IMAGE"
             "JPG" () NIL NIL "8bit" 4182 NIL NIL NIL)) 
         S: e001 OK UID CONVERT COMPLETED
///Now client can prepare its MIME viewer or decide not to download the part
         C: e002 CONVERT 2 (NIL) (BINARY[2])
         S: * 2 CONVERTED (TAG "e001") (BINARY[2]
             ~{4182}
            <image> 
            )
         S: e002 OK UID CONVERT COMPLETED

>   part types: application/octet-stream.
Philip,
We had a previous iteration of this discussion off-list, but I guess my 
arguments were not persuasive enough.
Let me try again.

>   the IMAP server what it can convert "that specific" MIME part to.
You haven't convinced me that the difference between "the server can 
convert ANY application/octet-stream to text/html, image/jpeg and 
video/foo" and "the server can convert THAT SPECIFIC 
application/octet-stream to text/html, image/jpeg and video/foo" is 
significant. If you can find a counter example, please let me know. Also 
see below.

>   specific" MIME part is about. So the client has no clue either.
GETMETADATA can list all possible target conversions for 
application/octet-stream.

>   I think the list of possible conversions should be queryable per
I am not convinced, as per above.

>  be different.
Well, yes. But the server can list all possible target conversions. A 
specific body part can be converted to a subset of such target types.

>And the client doesn't know anything whatsoever about
This would have been true without Dave Cridland's MEDIACAPS proposal. I 
think there is enough support for it that the CONVERT document should be 
updated to include it. Dave's proposal is as follows: at the beginning 
of an IMAP connection the client sends the server the MEDIACAPS command 
that lists all target MIME types supported by the client (order by 
client preference):

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

After that the server would know that a NIL conversion can only return 
one of the MIME types supported by the client.

>       converted data, that is already being received, to the user?
This statement is wrong, as downloading converted data is a separate 
operation from determining what it was converted to.
See my answer to your point # 1.

>   bandwidth until I'm finished sending.
As I said before, this statement is not true.

>S: A clue: I can do A B and C
Taking into considerations Dave's proposal, a client-server exchange can 
look like this:

C: I can digest B and C, I prefer B over C

<some time later>

C: I have no clue, convert this body part to something I understand and tell me what it is

S: I can convert this body part to B
(The client can also discover that the server can convert this MIME type to A, B, C and D)

C: Alright, so give me B

---

From: Philip Van Hoof <[email-masked]>
Date: Wed, 16 Jan 2008 12:49:27 +0100

>          S: e002 OK UID CONVERT COMPLETED

Aha! This example I didn't first see in the specification. Since there
are two separate steps, it's different from how I first interpreted it.

As in your comment, indeed at that point has the client the possibility
to prepare itself. Which makes that default answer more or less usable.

> updated to include it.

Oh, I haven't seen the MEDIACAPS proposal yet. I'll soon take a look at
this.

> Dave's proposal is as follows: at the beginning 

Interesting ...

> See my answer to your point # 1.

Yes, I misinterpreted the spec on that point. If it are two steps, then
the client can prepare itself for as long as it needs.

> (The client can also discover that the server can convert this MIME type to A, B, C and D)

Yes, and that conversation could work for the client.

Thanks for the clarifications.