Subject: RE: [lemonade] CONVERT: .STRICT specifier (again)

From: <[email-masked]>
Date: Wed, 9 May 2007 11:11:20 +0300

We removed SERVEROVERRIDE. I think removing .STRICT is pretty much the same argument.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: ext Alexey Melnikov [mailto:[email-masked]] 
>Sent: 29 April, 2007 16:44
>To: Lemonade WG
>Subject: [lemonade] CONVERT: .STRICT specifier (again)
>
>I am somewhat hesitating to remove .STRICT specifier. Are 
>there any cases when the client would like to specify a 
>transcoding parameter that can be ignored by the server?
>
>
>
>
>_______________________________________________
>lemonade mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/lemonade
>Supplemental Web Site:
>http://www.standardstrack.com/ietf/lemonade
>

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 May 2007 11:37:53 +0100

[email-masked] wrote:

>We removed SERVEROVERRIDE.
>
>I think removing .STRICT is pretty much the same argument.
>  
>
I think the draft used .STRICT to mean different things in different cases.

One was to prevent SERVEROVERRIDE, especially substitution of MIME type. 
The MIME type substitution is disallowed in the latest version, unless 
the client explicitly requests the default conversion.

Another use of .STRICT is to specify that conversion parameters are not 
optional. Imagine a client that would prefer that the target image has 
width X, but can cope with the case when the server ignores the width 
parameter, but otherwise perform the request. Do we want to be able to 
optimize for this case?

Without .STRICT (i.e. it is always implied) the client will have to 
issue the first conversion request with WIDTH. This conversion request 
will fail because the server can't comply. Then the client will have to 
reissue the request without WIDTH.
So the absence of .STRICT will allow for this optimization.

Another way of doing optional conversion parameters would be to remove 
.STRICT, but to allow for "optional." prefix in parameter names. I.e. 
"optional.width" would mean that the width parameter is option. This 
would actually be more flexible than "all or nothing" approach required 
by .STRICT.

---

From: <[email-masked]>
Date: Fri, 11 May 2007 16:32:58 +0300

Alexey,
my preference would be to always assume "STRICT": I am the client and I know what I want because I know what I am capable of. Either give it to me, or let's forget the whole thing (get error).
The only time I would leave the choice up the the server is when the client wants "default" conversion - leaving all conversion parameters to the server - however this is a different story.

For example:
I am a simple client, I show what I get (no scrolling or zooming). The display is 400*300, so I request conversion to 400*300. Now, if the server gave me anything else than this, I can't show the image properly since I do not have scrolling, or zooming facilities.

There is one useful option for keeping .STRICT. For example, I get an 1600*1000 picture, and I want to show it on a 400*300 display. So I request the server to convert this to 400*300 and do not specify .STRICT. The server is allowed to change a parameter, so it will give me a 400*250 picture (keeping the original aspect ratio).
Question is: will this be used in the future? I mean clients are getting better and better, so they should be able to handle such exceptions. Also, which parameters are the servers allowed to override? (I meam if I want MP3, I would not want a WAV instead).

Assuming always strict and indicating "optional" would be better.

Any thoughts?

Thank You.

>Sent: 10 May, 2007 13:38
>To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
>Cc: [email-masked]
>Subject: Re: [lemonade] CONVERT: .STRICT specifier (again)
>
>The MIME type substitution is disallowed in the latest 
>version, unless the client explicitly requests the default conversion.
>
>Another use of .STRICT is to specify that conversion 
>parameters are not optional. Imagine a client that would 
>prefer that the target image has width X, but can cope with 
>the case when the server ignores the width parameter, but 
>otherwise perform the request. Do we want to be able to 
>optimize for this case?
>
>Without .STRICT (i.e. it is always implied) the client will 
>have to issue the first conversion request with WIDTH. This 
>conversion request will fail because the server can't comply. 
>Then the client will have to reissue the request without WIDTH.
>Another way of doing optional conversion parameters would be 
>to remove .STRICT, but to allow for "optional." prefix in 
>parameter names. I.e. 
>"optional.width" would mean that the width parameter is 
>option. This would actually be more flexible than "all or 
>nothing" approach required by .STRICT.
>
>>>I am somewhat hesitating to remove .STRICT specifier. Are there any 
>>>cases when the client would like to specify a transcoding parameter 
>>>that can be ignored by the server?
>>>    
>>>
>
>
>