Subject: [lemonade] Open Issues with IMAP CONVERT

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Mar 2007 15:22:48 +0100

Hi,
I've done some work on updating the CONVERT draft. I found more issues 
that need to be discussed.
Some of the major issues are listed below:

1). Do we want to allow for conversion of non-leaf bodyparts? E.g. 
multipart/related to application/pdf?

 I am slightly in favor of allowing this, even though I don't think that 
any server should be required to
 perform such conversions.

On a related note: should we allow to convert to non-leaf bodyparts?

2). draft -05 currently allows for default conversion (i.e. "just 
convert to any media type, you know best").
I don't think this should be allowed and I suggest removing this feature 
from ABNF.

Somewhat related to this: is the server allowed to convert to image/png 
instead of image/jpeg when .STRICT
suffix to CONVERT is not specified? (I don't think this should be allowed)

3). There is one big issue surrounding INFORMATIONLOSS. I will publish 
an updated draft shortly, but it will not tackle this issue. I will try 
to address the issue in the subsequent revision.

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

---

From: <[email-masked]>
Date: Thu, 29 Mar 2007 10:28:57 +0300

Alexei,

> I am slightly in favor of allowing this, even though I don't 
>think that any server should be required to  perform such conversions.
>

Support++

>2). draft -05 currently allows for default conversion (i.e. 
>"just convert to any media type, you know best").
>I don't think this should be allowed and I suggest removing 
>this feature from ABNF.

OMA has a requirement for the server making the decision (based on some
capability information about the client) and I think this is our "hook"
to do that. Removing it would complicate our lives in OMA. I would like
to ask You to re-consider this proposal.

>Somewhat related to this: is the server allowed to convert to 
>image/png instead of image/jpeg when .STRICT suffix to CONVERT 
>is not specified? (I don't think this should be allowed)

I don't think it should be allowed.
In fact, I think STRICT should be removed and if the server cannot
fulfill the convert then it should fail the request. I think mosts
client would add it there anyway because they want exactly what they
asked for - and nothing else. If clients don't want to convert to some
specific type, they will let the server decide the best conversion.

>3). There is one big issue surrounding INFORMATIONLOSS. I will 
>publish an updated draft shortly, but it will not tackle this 
>issue. I will try to address the issue in the subsequent revision.

Could You elaborate this, please?
Thank You.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Mar 2007 16:06:07 +0100

I have one more additional issue with CONVERT (so far):

4). CONVERT uses the '*' character in annotations to signal "any media 
type" or "any subtype". However '*' is not allowed in annotation names. 
Any objections to changing this to the '@' character?

[FYI, ABNF for media type or subtype is:
       reg-name-chars = ALPHA / DIGIT / "!" /
                       "#" / "$" / "&" / "." /
                       "+" / "-" / "^" / "_"
So, I would like to pick a character that can never occur in a media 
type/subtype name]

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Mar 2007 16:32:09 +0100

Hi Zoltan,

>to ask You to re-consider this proposal.
Considering your anwer to the related question below, I am now Ok with 
keeping this.

Is support for this feature optional for a general IMAP server?
I think the answer is "yes". But OMA can make this a required feature.

>specific type, they will let the server decide the best conversion.
Your suggestion will work for me. It will certainly make the document 
simpler to read and implement.

>Could You elaborate this, please?
The issue is how the client can figure out which bodypart was converted 
with loss when the client requested multiple conversions in a single 
FETCH command.
Some suggested to use URLs to identify the bodypart. Arnt wrote the 
following:

> Serious: I don't like the INFORMATIONLOSS response code - it's on the 
> wrong response. As it stands, it means "one or more of the preceeding 
> untagged responses is approximate rather than exact". Either it should 
> be a flag on BODYPARTSTRUCTURE to show exactly which conversion is 
> approximate, or it should carry some arguments to specify the inexact 
> bodypart(s).

---

From: <[email-masked]>
Date: Fri, 30 Mar 2007 11:03:56 +0300

Hi Alexei,

>>>I don't think this should be allowed and I suggest removing this 
>>>feature from ABNF.
>>>    
>>>
>Considering your anwer to the related question below, I am now 
>Ok with keeping this.
>

It will be a MUST in OMA. You can mandate it, but I sense that this is
something You would not want to do - and I have to agree since OMA will
provide the means to get capability information about the client.

>>>image/png instead of image/jpeg when .STRICT suffix to 
>CONVERT is not 
>>>specified? (I don't think this should be allowed)
>>>    
>>>
>Your suggestion will work for me. It will certainly make the 
>document simpler to read and implement.

As long as my proposal is OK with everyone else.

>>>an updated draft shortly, but it will not tackle this issue. I will 
>>>try to address the issue in the subsequent revision.
>>>    
>>>
>The issue is how the client can figure out which bodypart was 
>converted with loss when the client requested multiple 
>conversions in a single FETCH command.

Can we take a moment and think about why we need this?
I mean I am not sure that we need this:
 - Probably no client will upscale->no loss.
 - Most clients will downscale -> there is always loss.
 - Some clients might use format/size conversions-> If client requests
explicit conversion, it should be aware that there might be loss, while
if the client left the conversion choice up to the server, it should
assume that there was a loss.
What do You think?