Subject: [lemonade] RE: imap convert (and IMAP URLS and CATENATE)

From: Peter Coates <[email-masked]>
Date: Wed, 19 Sep 2007 14:21:07 -0700

One point I meant to make in this node, but failed to is that if the CONVERTED
response has the form
* msgno CONVERTED (tag zzz) ...
Then the CONVERTERROR response should also.

Peter 

-----Original Message-----
From: Peter Coates [mailto:[email-masked]] 
Sent: September 19, 2007 12:09
To: [email-masked]'
Subject: imap convert (and IMAP URLS and CATENATE)

I have a number of issues with CONVERT.  These are mostly to do with error
reporting and preflighting.  URLs and CATENATE come into play as either part of
a solution or having similar issues.
 
There is text in the CATENATE document at the end of section 7.3 that says
"Servers MAY refuse to execute a conversion request that converts multiple
messages at once, i.e. a conversion request that specifies multiple message
numbers/UIDs".
 
Let's look at WHY a server may want to do this.  The reason that is presumably
in the mind of the author is to do with preflighting, where a client asks for
the size of a converted body part then asks for the body itself... the server
should cache the result and having the constraint of one conversion at a time
really helps there.
 
Now lets look at the HOW.  How does the server tell the client about this
restriction?  The syntax is good, so the response has to be a NO, but I see no
obvious resp-text-code to explain the restriction.
 
Suppose the server did not impose this restriction, and the client made the
following request:
 
         C: e001 CONVERT 2,3 (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2]
             BODYPARTSTRUCTURE[2])

Suppose further that body[2] of message 2 was an image/jpeg, but body[2] of
message 3 was text/plain, or not present.  What is the server supposed to do?
Is it supposed to reject the whole command (which required a lot of look ahead)?
Is it supposed to return the converted body for message 2, and a CONVERTERROR
for message 3?  if body[2] does not exist in msgno 3 what should the
CONVERTERROR contain?  I do not see how this case is handled.  Do we use a
pseudo mime type of NIL as the from mime type?
If at least one message part is successfully converted, i.e. at least one
CONVERTED response is returned, then presumably the tagged response has to be OK
regardless of any CONVERTERROR responses that may accompany it.  Which begs the
question as to why we say NO if the all fail.  That is not the behaviour of
fetch:
1 fetch 1:* body[8]
* 1 FETCH (BODY[8] NIL)
* 2 FETCH (BODY[8] NIL)
* 3 FETCH (BODY[8] NIL)
* 4 FETCH (BODY[8] NIL)
* 5 FETCH (BODY[8] NIL)
* 6 FETCH (BODY[8] NIL)
* 7 FETCH (BODY[8] NIL)
* 8 FETCH (BODY[8] NIL)
* 9 FETCH (BODY[8] NIL)
1 OK Completed
 
Now lets go back to the preflighting, where a client asks for the size then
(maybe) the data.  The problem here is that the server is expected to cache some
results.  this is a load on the server that is transparent to the client and an
anomaly for the server.  I suggest instead that we augment the IMAP URL syntax
adding an optional /;convert= part to it and a ;encoding= parameter.  Thus if a
client wanted the server to perform a conversion but not yet down load the
result it could say something along the lines of
 
a append Drafts CATENATE (TEXT {nnn}
From: "peter" <[email-masked]>
To: "peter" <[email-masked]>
Subject: Converted Body
Date: Wed, 19 Sep 2007 01:01:53 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="----=_NextPart_000_0033_01C7FA98.EC0768B0"
 
This is a multi-part message in MIME format.
 
------=_NextPart_000_0033_01C7FA98.EC0768B0
Content-Type: image/jpeg;
        name="DSC00317.JPG"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="DSC00317.JPG"

URL
"/INBOX/;uid=42/;section=2/;convert=(%22IMAGE/JPG%22%20(%22PIX-X%22%20%22128%22%
20%22PIX-Y%22%20%2296%22))" TEXT {nn}

------=_NextPart_000_0087_01C7FAAA.231A29D0--
)
 
Then the client can ask for the size of the thing, forward it, etc, etc.
If the conversion can not be carried out, then the append command would reply a
NO [BADURL /INBOX/... conversion error] [CONVERTERROR ...]
 
Except that a response can only carry one structured response field.  We could
put the converterror information in the BADURL response, but that has no
structure after the URL.  Shame it does not have some more structure, eg

a NO [BADURL /INBOX/... BADURLSYNTAX ...] a NO [BADURL /INBOX/... BADUID ...] a
NO [BADURL /INBOX/... BADSECTION ...] a NO [BADURL /INBOX/... CONVERTERROR ...]

Too late to fix that, I suppose.

----------
 
Trivial point: the syntax of missing-parms in the CONVERTERROR response is as
follows
 
      missing-params = "MISSINGPARAMETERS"
                           1*(SP mime type-and-params)

      mime type-and-params = from-concrete-mime-type SP to-mime-type
              SP "(" transcoding-params ")"

      transcoding-params  = transcoding-param 
                            *(SP transcoding-param) 

      transcoding-param  = transcoding-param-name SP
                           transcoding-param-value 

Presumably if the parameter is missing, then the transcoding-param-value
reported in the error response is NIL?
 
eg
aa NO [CONVERTERROR MISSINGPARAMETERS text/plain text/plain (charset nil)]

Peter

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

---

From: Peter Coates <[email-masked]>
Date: Wed, 19 Sep 2007 15:29:03 -0700

Another point about convert.  The syntax allows for insane commands like

e001 CONVERT 2:* (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2]
BODYPARTSTRUCTURE[1]) 

There are two insanities about this command.  First the idea that I might want
the same conversion on the nth body part in multiple messages is a joke.
Secondly the idea that I might want the BINARY of a particular conversion of one
part and the body structure from applying that conversion to another part is not
even funny.

Ignoring the multiple messages part of this, this tells me that there is
something fishy about the syntax of the command.
(1) it allows me to do something absurd
(2) it wastes bandwidth having me specify the same thing twice.

What the client really wants to specify is a body part in a message and what
data it wants back.  The command should perhaps look more like

e001 CONVERT 2[1.1] (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY
BODYPARTSTRUCTURE)

While were at it, what do all these parentheses achieve for us?  Why could the
command not look like

e001 CONVERT 2[1.1] (NIL "PIX-X" "128" "PIX-Y" "96") BINARY BODYPARTSTRUCTURE

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter
Coates
Sent: September 19, 2007 14:21
To: 'Peter Coates'; [email-masked]
Subject: RE: imap convert (and IMAP URLS and CATENATE)

Peter 

-----Original Message-----
From: Peter Coates [mailto:[email-masked]]
Sent: September 19, 2007 12:09
To: [email-masked]'
Subject: imap convert (and IMAP URLS and CATENATE)

 

 

 

URL

 

----------

 
eg

Peter

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 23 Sep 2007 11:38:48 +0100

>e001 CONVERT 2[1.1] (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY
This would make the CONVERT command syntax unnecessarily different from 
the FETCH command syntax. (They are already slightly different, but this 
would make it even more different). So before changing the document I 
would need to hear at least one more voice in favor of this change.

>While were at it, what do all these parentheses achieve for us?
>
Possible extensibility of the CONVERT command in the future.

>Why could the command not look like
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 23 Sep 2007 11:38:48 +0100

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 22 Sep 2007 23:52:17 +0100

>Then the CONVERTERROR response should also.
I like this.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 22 Sep 2007 23:52:17 +0100

I like this.