Re: [lemonade] Open Issues with IMAP CONVERT

[Alexey Melnikov <alexey.melnikov at isode.com>]

Hi Zoltan,

Zoltan.Ordogh at nokia.com wrote:

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

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

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



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