Subject: Re: [lemonade] POLL: discovery of available conversions in CONVERT

From: Alexey Melnikov <[email-masked]>
Date: Fri, 01 Feb 2008 17:38:51 +0000

Alexey Melnikov wrote:

> Hi everyone,
> After reviewing comments on CONVERT capability discovery received 
> during and after WG LC it looks like there is no consensus (at least 
> not yet) to use any particular mechanism. Please correct me if you 
> think otherwise.
>
> So in order to figure out if the WG prefers any particular mechanism I 
> suggest that people answer the following questionnaire. Some questions 
> allow for multiple choices. Please list them in the order of your 
> preferences.
>
> In order to correctly answer the questionnaire, one needs to:
> 1). have basic understand about CONVERT, ideally read 
> draft-ietf-lemonade-convert-13.txt
> 2). review draft-daboo-imap-annotatemore-12.txt
> 3). review draft-melnikov-lemonade-convert-discovery-00.txt
>
> Please either send your replies to the Lemonade WG mailing list, or if 
> you prefer - directly to me, CCing Peter Coates 
> <[email-masked]>, Eric Burger <[email-masked]>, Glenn Parsons 
> <[email-masked]>.
>
> Please send your response before February 8th.

Folks,
There is only one week left for the poll and I only got 2 responses. I 
am expecting at least 5 responses from usual suspects. Please respond, 
or I will start bugging your directly.

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

---

From: Philip Van Hoof <[email-masked]>
Date: Mon, 04 Feb 2008 12:52:37 +0100

On Fri, 2008-01-25 at 18:03 +0000, Alexey Melnikov wrote:

> ==========================================
> 
> Q1: Some questions regarding understanding of METADATA-SERVER 
> (draft-daboo-imap-annotatemore-12.txt) extension (please answer to each 
> question with Yes (true) or No (false))
> 
> A). METADATA-SERVER depends on LIST-EXTENDED extension 
> (draft-ietf-imapext-list-extensions-18.txt).

Yes (Introduction and overview explicitly states this)

> B). METADATA-SERVER depends on ENABLE extension 
> (draft-gulbrandsen-imap-enable-05.txt).

Yes (Introduction and overview explicitly states this)

> C). A server implementing METADATA-SERVER must implement multiple 
> comparators.

Not sure

> D). METADATA-SERVER requires implementation of both .priv and .shared

Section 3.3 mentions this, so yes.

> Q2: Should CONVERT support the following conversion discovery mechanism: 
> "Give me this body part in a format that I probably understand"
> (feel free to select multiple answers, unless you answer No or Undecided)

1) No: CONVERT should allow me to specify "exactly" what the format will
be and "exactly" what it can give me, before actually giving it.

The word "probably" is meaningless for a client. "Probably" means that
equally probable it wont work. 

> Answers:
> 1). No
> 2). Yes, I am happy with Dave Cridland's proposal (see section 2.1 of 
> draft-melnikov-lemonade-convert-discovery-00.txt or 
> <http://www1.ietf.org/mail-archive/web/lemonade/current/msg04264.html>)
> 3). Yes, but I would like to suggest another proposal
> 4). Undecided

> Q3: Should CONVERT support the following conversion discovery mechanism: 
> "What can I turn this body part into?"
> (feel free to select multiple answers, unless you answer No or Undecided)

Yes

2) CONVERSIONS, it seems, only tells me globally what conversions are
possible. It doesn't seem allow me to ask: What can you convert "this
specific MIME part of this specific message in this specific folder" to.

Something like this would be useful:

C: 1 SELECT INBOX
S: ...
S: 1 OK SELECT completed
C: 2 UID CONVERSIONS 3 (2.1)
S: * CONVERT "image/jpeg" ("width" "height" "depth")
S: * CONVERT "application/pdf"
S: * CONVERT "image/png" ("width" "height" "depth")
S: 2 OK CONVERSIONS completed

> Answers:
> 1). No
> 2). Yes, I prefer to use METADATA-SERVER extension (see section 2.2.1 of 
> draft-melnikov-lemonade-convert-discovery-00.txt, also see 
> draft-daboo-imap-annotatemore-12.txt for more information)
> 3). Yes, I prefer to use Dan Karp's proposal (see section 2.2.2 of 
> draft-melnikov-lemonade-convert-discovery-00.txt or 
> <http://www1.ietf.org/mail-archive/web/lemonade/current/msg04297.html>)
> 4). Yes, I prefer Arnt's proposal for advertising target MIME types (or 
> similar tokens) in the CAPABILITY response, e.g.:
> 
> * CAPABILITY ... CONVERT=JPEG ... CONVERT=MP3 ...

1) No

Same as #2: only globally support conversions are possible to know
about.

> 5). Yes, but I would like to suggest another proposal
> 6). Undecided
> 
> 
> Q4: Should CONVERT support discovery of available conversion parameters 
> for a particular conversion?
> (feel free to select multiple answers, unless you answer No or 
> Undecided) Note that a separate question is asking if discovery should 
> be optional or mandatory for servers to implement.
> 
> Answers:
> 1). No, reporting that a particular conversion parameter is not 
> supported (see CONVERT draft) is sufficient
> 2). Yes, I prefer to use METADATA-SERVER extension (see section 2.2.1 of 
> draft-melnikov-lemonade-convert-discovery-00.txt, also see 
> draft-daboo-imap-annotatemore-12.txt for more information)
> 3). Yes, I prefer to use Dan Karp's proposal (see section 2.2.2 of 
> draft-melnikov-lemonade-convert-discovery-00.txt or 
> <http://www1.ietf.org/mail-archive/web/lemonade/current/msg04297.html>)

> 4). Yes, I would prefer to list available conversion parameters upon a 
> CONVERT command failure caused by an unrecognized conversion parameter, 
> for example:

4) Sounds usable

>       C: b002 CONVERT 2 ("text/plain" ("mumble" "hrrr"))
>           (BINARY[3] BODYPARTSTRUCTURE[3])
>       S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3]
>           (ERROR "Parameter mumble is not supported for text/plain" 
> BADPARAMETERS
>           "text/html" "text/plain" ("mumble" "hrrr")))
>       S: * CONVERSIONS "text/html" "text/plain" "charset" 
> "UNKNOWN-CHARACTER-REPLACEMENT"
>       S: b002 OK Some conversions failed  
> 
> 5). Yes, but I would like to suggest another proposal
> 6). Undecided
> 
> 
> Q5: If you answered Yes to Q4: should the conversion parameter discovery 
> be Mandatory or Optional for servers to support?

Mandatory

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

---

From: <[email-masked]>
Date: Mon, 4 Feb 2008 17:10:31 +0200

Alexey and Philip,

Philip wrote:

>> Undecided)
>1) No: CONVERT should allow me to specify "exactly" what the 
>format will be and "exactly" what it can give me, before 
>actually giving it.

Now, I understood the question in a way that if there was support for "Give me this body part in a format that I probably understand" then it does not mean exclusion of Philip's "exact" conversion (and vice versa). Is my understanding correct, or these are meant to be mutually exclusive?

Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566
_______________________________________________
lemonade mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 04 Feb 2008 15:17:12 +0000

[email-masked] wrote:

>Now, I understood the question in a way that if there was support for "Give me this body part in a format that I probably understand" then it does not mean exclusion of Philip's "exact" conversion (and vice versa).
>
You are correct.
Philip slightly misunderstood my question.

>Is my understanding correct, or these are meant to be mutually exclusive?
>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 08 Feb 2008 23:02:55 +0000

7 people have replied to the questionnaire (including myself). Below are 
the results:

Alexey Melnikov wrote:

> (draft-daboo-imap-annotatemore-12.txt) extension (please answer to 
> each question with Yes (true) or No (false))
>

I am highly disappointed that most of the people got answers to this 
question wrong.
Correct answers:
A). No
B). Yes
C). No
D). No

> Q2: Should CONVERT support the following conversion discovery 
> mechanism: "Give me this body part in a format that I probably 
> understand"

Most of the people are in favor of 2. Some people were undecided, but 
not against it.
So, I will be adding Dave's proposal to the next revision of CONVERT.

> Q3: Should CONVERT support the following conversion discovery 
> mechanism: "What can I turn this body part into?"
> 2). Yes, I prefer to use METADATA-SERVER extension (see section 2.2.1 
> of draft-melnikov-lemonade-convert-discovery-00.txt, also see 
> 4). Yes, I prefer Arnt's proposal for advertising target MIME types 
> (or similar tokens) in the CAPABILITY response, e.g.:
>

Consensus on this question was rough:

2 people were against this (choice 1). Everybody else were in favor of 
one of the yes choices (2, 3 or 4). Among these people, majority 
preferred choice 3, with choices 2 and 4 both being the second favorite 
choice.

So I think we will go with Dan's proposal.

> Q4: Should CONVERT support discovery of available conversion 
> parameters for a particular conversion?
> 2). Yes, I prefer to use METADATA-SERVER extension (see section 2.2.1 
> of draft-melnikov-lemonade-convert-discovery-00.txt, also see 
> CONVERT command failure caused by an unrecognized conversion 
> parameter, for example:
>

Consensus on this question was even more rough.

One person was against this (i.e. choice 1).
Choices 3 and 4 had about equal number of votes (counting peoples second 
choices), so I think I will need to poll people again to confirm which 
one of those two they prefer.

> Q5: If you answered Yes to Q4: should the conversion parameter 
> discovery be Mandatory or Optional for servers to support?

Most people thought that it should be mandatory.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 9 Feb 2008 21:29:25 +0100

Alexey Melnikov writes:
>> mechanism: "What can I turn this body part into?" (feel free to 
>> select multiple answers, unless you answer No or Undecided)
>>
>>  Answers:
>>  1). No
> preferred choice 3, with choices 2 and 4 both being the second 
> favorite choice.

Two votes for 1, one for 2, three for 3 and one for 4? Rough indeed.

> So I think we will go with Dan's proposal.

I kind of like Dan's proposal, but if listing a conversion is a promise, 
then it's a hard one to keep. Even if my code supports TIFF or Flash it 
may not be able to convert a particular TIFF or Flash file to the 
desired format.

And IIRC Dan's proposal ignores all the attachments that are sent with 
c-t application/octet-stream.

Artn

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Feb 2008 22:49:11 +0000

>Two votes for 1, one for 2, three for 3 and one for 4? Rough indeed.
Actually, it was 2 votes for 1, 2 votes for 2, 3 votes for 3, 1 vote for 
4. And I've made a mistake: 8 people answered to my poll request.
On top of that, one person specified 3 as the second preferred choice.

>may not be able to convert a particular TIFF or Flash file to the 
I had an offline conversation with Philip van Hoof and he convinced me 
that we need a way to discover available conversions for a specific body 
part.
So, unless somebody objects, I will also be adding a new CONVERT data 
item for requesting a list of available conversions.

>c-t application/octet-stream.
I don't think this is true. Surely a server can respond:

    C: a CONVERSIONS "application/octet-stream" "*"   
    S: * CONVERSION "application/octet-stream" "image/jpeg" ("width" 
"height"
        "depth" "interlaced")
...<and ten thousands other CONVERSION responses for other media types>...
    S: a OK CONVERSIONS completed

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 15 Feb 2008 13:07:06 +0100

Alexey Melnikov writes:
> that we need a way to discover available conversions for a specific 
> body part.

I can see why. I remain unconvinced that we need more than one target 
format for any given data domain, though.

> item for requesting a list of available conversions.

Good. Add some wording about performance and semantics. If the server 
says it can translate 4.2.4 to x/y, is the conversion allowed to fail 
later?

Sometimes you only discover very late that a particular conversion isn't 
possible, so if the server is to discover a _real_ list of what it can 
do, it may have to do work proportional to both the number of target 
formats and the size of the input.

I'd prefer to have mostly correct list quickly, even if a few weird 
cases might not work.

>> And IIRC Dan's proposal ignores all the attachments that are sent 
>> with c-t application/octet-stream.

> I don't think this is true. Surely a server can respond:

Your example contains half a megabyte of responses, which IMO makes it a 
no-no in Lemonade.

I don't really dislike Dan's proposal, but I do think it's beside the 
problem since it relates to the declared MIME type rather than the 
actual data type. With dozens of types all called "application/flash" 
and thousands often mislabelled "application/octet-stream" that's a 
significant difference.

Philip's bodypart-based approach is better, but IMO the really useful 
approach is to let the client ask for conversions to downscaled JPG and 
downsampled MP3 without having to go through any foreplay.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 15 Feb 2008 13:33:41 +0100

Arnt Gulbrandsen writes:
> approach is to let the client ask for conversions to downscaled JPG 
> and downsampled MP3 without having to go through any foreplay.

I wouldn't mind combining those. It seems possible to share syntax, and 
Dan's seems easy to implement on top of Philip's. CONVERSION could have 
a NIL to mark it as general or a UID/section to mark it as pertaining 
to that bodypart.

Btw. I said it before, but it was easy to overlook. The syntax you've 
posted today and before allows only downscaling a given size, and 
that's usually not a good solution. There are three options:
1. Scale to the exact dimensions provided, disregarding aspect ratio.
2. Keep the aspect ratio and make the result smaller if necessary ("give 
me the biggest that fits my screen/window").
3. Keep+bigger ("give me something that needs at most one scrollbar)".

Please add an argument to select the type of scaling. Perhaps scale-type 
= "fit-within" / "exact-size" / "encompass".

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Feb 2008 12:44:04 +0000

Arnt Gulbrandsen wrote:

> 2. Keep the aspect ratio and make the result smaller if necessary 
> ("give me the biggest that fits my screen/window").
> Please add an argument to select the type of scaling. Perhaps 
> scale-type = "fit-within" / "exact-size" / "encompass".

This should be another conversion parameter registered with IANA. It 
should be defined in a document separate from the base CONVERT extension.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 17 Feb 2008 16:05:22 +0000

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Arnt Gulbrandsen wrote:
>>
>>> I meant the CONVERSION response, not the CONVERSIONS command.
>>
>> And I meant the CONVERTED response ;-).
>
> You mean that you want to have CONVERSION and CONVERTED responses, and 
> sometimes CONVERTED carries a converted bodypart and sometimes it 
> carries informtation about a conversion? Uh...

Yes, this actually doesn't look too bad:

         C: f001 CONVERT 2 (NIL) (AVAILABLECONVERSIONS[2])
         S: * 2 CONVERTED (TAG "f001") (AVAILABLECONVERSIONS[2] 
(("IMAGE/JPEG" "application/PostScript"))
         S: f001 OK CONVERT COMPLETED

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 17 Feb 2008 15:13:02 +0000

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Arnt Gulbrandsen wrote:
>>
>>> I wouldn't mind combining those. It seems possible to share syntax, 
>>> and Dan's seems easy to implement on top of Philip's. CONVERSION 
>>> could have a NIL to mark it as general or a UID/section to mark it 
>>> as pertaining to that bodypart.
>>
>> I prefer to extend the CONVERT command itself, because:
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 16 Feb 2008 21:29:40 +0000

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> I had an offline conversation with Philip van Hoof and he convinced 
>> me that we need a way to discover available conversions for a 
>> specific body part.
>
> Good. Add some wording about performance and semantics.

Will do.

> If the server says it can translate 4.2.4 to x/y, is the conversion 
> allowed to fail later?

Yes. This operation shouldn't be too slow.

> Sometimes you only discover very late that a particular conversion 
> isn't possible, so if the server is to discover a _real_ list of what 
> it can do, it may have to do work proportional to both the number of 
> target formats and the size of the input.

Right.

> I'd prefer to have mostly correct list quickly, even if a few weird 

Agreed.

> Your example contains half a megabyte of responses,

Yes, it is possible.

> which IMO makes it a no-no in Lemonade.

I can add a warning about this, but I am not sure we can do much better 
than that.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 16 Feb 2008 16:47:19 +0000

Arnt Gulbrandsen wrote:

> and Dan's seems easy to implement on top of Philip's. CONVERSION could 
> have a NIL to mark it as general or a UID/section to mark it as 
> pertaining to that bodypart.

I prefer to extend the CONVERT command itself, because:
1). it already has parameters for message number/UID and body part number.
2). CONVERSIONS can (*) be implemented as more or less static table of 
MIME types and parameters.

(*) - but doesn't have to. It depend if an implementation is pluggable 
or not.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 17 Feb 2008 18:31:41 +0100

>         S: f001 OK CONVERT COMPLETED

Not too bad.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 17 Feb 2008 16:43:42 +0100

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 17 Feb 2008 16:10:45 +0100

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Feb 2008 15:54:39 +0000

Alexey Melnikov wrote:

>> Undecided) Note that a separate question is asking if discovery 
>> should be optional or mandatory for servers to implement.
>>
>> Answers:
>> 4). Yes, I would prefer to list available conversion parameters upon 
>> a CONVERT command failure caused by an unrecognized conversion 
>> parameter, for example:
>>
> Choices 3 and 4 had about equal number of votes (counting peoples 
> second choices), so I think I will need to poll people again to 
> confirm which one of those two they prefer.

Choice 3 was slightly favored by some people. That is what I've done in -15.
Unless somebody would suggest syntax for 4 and can argue why it is much 
better, the document would stay as is.