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

From: Peter Coates <[email-masked]>
Date: Wed, 19 Sep 2007 12:09:20 -0700

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: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Sep 2007 22:43:34 +0100

>obvious resp-text-code to explain the restriction.
Right. In my [unpublished] revision 12 I've added a new subresponse of 
the CONVERTERROR response:

   TOOMANYCONVERSIONS - the request has specified conversion of multiple
   messages or body parts. This would result in a need to store multiple
   converted messages and the number of converted messages exceeds the
   maximum number supported by the server or allowed by its policy.

Now, I wasn't sure that this is actually needed. The main reason is that 
I don't think that the server needs to cache more than one converted 
part at any given time. Even if the client has requested conversions of 
multiple bodyparts, the server can perform conversion 1, then 
immediately return it to the client, then perform conversion 2, then 
return it to the client, etc.

>Is it supposed to reject the whole command (which required a lot of look ahead)?
No, this wasn't the intent.

>for message 3?
Yes. Now, CONVERTERROR doesn't contain any message number, but this can 
be easily added.

>if body[2] does not exist in msgno 3 what should the
>CONVERTERROR contain?
>
BADPARAMETERS, i.e. the source MIME type can't be converted to the 
destination MIME type.

>I do not see how this case is handled.  Do we use a pseudo mime type of NIL as the from mime type?
>  
>
Yes, this would work (I would need to extend syntax to allow for that)

>question as to why we say NO if the all fail.
>
I don't think this would make much practical difference for clients. 
They need to handle the tagged NO, as well as tagged OK + untagged 
CONVERTERROR.

>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
> 
>adding an optional /;convert= part to it
>
I think you've missed section 9.1 in revision 11, it already contains 
something like this.

>and a ;encoding= parameter.
>
This would convey Content-Transfer-Encoding, right?

>  Thus if a
This would be doable, if we create a new response code or extend 
existing one. As long as the new response code is optional, it can be 
included in CATENATEbis.

>                           1*(SP mimetype-and-params)
>
>      mimetype-and-params = from-concrete-mime-type SP to-mime-type
Thanks for spotting this.

>aa NO [CONVERTERROR MISSINGPARAMETERS text/plain text/plain (charset nil)]
No, the transcoding-params should be optional, the same way as it is 
optional in the request:

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