RE: [lemonade] Open Issues with IMAP CONVERT

[<Zoltan.Ordogh at nokia.com>]

Hi Alexei,

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

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.

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

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

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?

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade