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

From: Alexey Melnikov <[email-masked]>
Date: Fri, 25 Jan 2008 18:03:28 +0000

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

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).
B). METADATA-SERVER depends on ENABLE extension 
(draft-gulbrandsen-imap-enable-05.txt).
C). A server implementing METADATA-SERVER must implement multiple 
comparators.
D). METADATA-SERVER requires implementation of both .priv and .shared

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)

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)

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

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:

      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?

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

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Jan 2008 22:16:23 +0000

I've answered other bits of this to the relevant people privately.

> <http://www1.ietf.org/mail-archive/web/lemonade/current/msg04297.html>)

I basically like CONVERSIONS, but I wonder if it'd be possible to  
extend it so that you could either specify a source MIME type, or a  
source part.

So you could say not only "What can you do with image/gif parts?" but  
also "What can you do with part 1.2.3 of UID 54?".

As a suggested syntax:

tag CONVERSIONS (UID 54 1.2.3) *

> 4). Yes, I prefer Arnt's proposal for advertising target MIME types  
> (or similar tokens) in the CAPABILITY response, e.g.:
> 
I like the notion of this, but I wonder if it's ever going to go far  
enough. On the other hand, such a proposal does have the distinct  
benefit of being really simple for simple use-cases.

So it's convenient to have a rubber stamp "I do these types of  
conversions", but that won't always be enough, and it also leaves  
open the rather tricky can of worms about which "standard conversion  
sets" we define and how.

I also suspect that precisely what conversions are possible is likely  
to be a key differentiating factor between vendors, and that tying  
this down so that (honest) competition isn't possible would be a  
mistake that would cost the market as a whole.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 26 Jan 2008 16:27:42 +0000

> also "What can you do with part 1.2.3 of UID 54?".

Do we really need this?

> tag CONVERSIONS (UID 54 1.2.3) *

If we do need this, I suggest we extend the CONVERT command itself 
instead: just add a new data item requesting the list of all available 
conversions.

---

From: <[email-masked]>
Date: Mon, 28 Jan 2008 10:39:18 +0200

Hi Alexey,
please find my answers below.

Q1:
===
A - yes (in case mailbox annotation is supported)
B - yes (always)
C - no (if there is none though, unicode-casemap is mandatory)
D - yes (though not explicitly stated -> improve text?)

Q2:
===
2. Note: it looks good on paper, the question is how efficient and useful this will be in practice (when will a client declare it, client has to remember that it has declared it already, what happens if it was not declared, etc).

3. While Dave's proposal is good, it might seem a logical choice to store the client capabilites as METADATA (or, some other form) so that it does not need to be disclosed during each session. This seems like a good candidate for the client identification draft as well. Some vendors expressed their concerns about the METADATA extension though - so it might not be such a good idea in the end.

Q3:
===
1. If "I do not know what this thing can be turned into", it might be more efficient to ask the server "just give me something I understand".

5. I suggested earlier to allow the client to request anything, and return the possible conversions only when there was an error. Arnt's proposal (advertise the list of MIME types) would imrove this: the MIME type chosen by the client will be always correct and only the parameters could be wrong.

Q4:
===
4. See improvement suggestion (using Arnt's proposal) above: Q3/5.

Q5:
===
I think that answer Q4/4 implies that it would be mandatory.

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: 25 January, 2008 20:03
>To: Lemonade WG
>Subject: [lemonade] POLL: discovery of available conversions in CONVERT
>
>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.
>
>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]>.
>
>(draft-daboo-imap-annotatemore-12.txt) extension (please 
>answer to each question with Yes (true) or No (false))
>
>C). A server implementing METADATA-SERVER must implement 
>multiple comparators.
>Undecided)
>2). Yes, I am happy with Dave Cridland's proposal (see section 
>2.1 of draft-melnikov-lemonade-convert-discovery-00.txt or
>3). Yes, but I would like to suggest another proposal 4). Undecided
>
>
>Undecided)
>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 
>4). Yes, I prefer Arnt's proposal for advertising target MIME 
>types (or similar tokens) in the CAPABILITY response, e.g.:
>
>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?
>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-daboo-imap-annotatemore-12.txt for more information) 3). 
>Yes, I prefer to use Dan Karp's proposal (see section 2.2.2 of 
>4). Yes, I would prefer to list available conversion 
>parameters upon a CONVERT command failure caused by an 
>unrecognized conversion parameter, for example:
>
>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?
>
>
>