Subject: [lemonade] CONVERT, CONVERTED, and CONVERTERROR

From: Peter Coates <[email-masked]>
Date: Wed, 26 Sep 2007 08:50:36 -0700

the current IMAP CONVERT DRAFT has some inconsistencies which become very clear
when you try to implement it.  The draft states:
 
A successful CONVERT/UID CONVERT command results in one or more
       untagged CONVERTED responses (one per message). They are similar
       to the untagged FETCH responses.
 
So far so good.  when things work, the draft is just fine.  It is when things go
wrong that problems start to emerge.  An example given in the draft is
 
 Example:  The client requests for conversion of a text/html body part
   to text/plain and asks for a charset of us-ascii.  The server cannot
   respect the charset conversion request because there are non-us-ascii
   characters in the text/html body part, so it fails the request with
   tagged NO response, preceded by the CONVERTERROR BADPARAMETERS response
   (see section 8
<http://tools.ietf.org/html/draft-ietf-lemonade-convert-11#section-8> ).

      C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii")) BINARY[3]
      S: * CONVERTERROR BADPARAMETERS text/html text/plain ("charset"
          "us-ascii")
      S: b001 NO Source text has non us-ascii

But what if the command had been 
 
      C: b002 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) BINARY[3]
 
or

      C: b003 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) 
                 BODYPARTSTUCTURE[2] BINARY[2] 
                 BODYPARTSTUCTURE[3] BINARY[3]
 
and some conversions succeed and some fail?  my first thought on this was to
move the error text from the tagged response and put the message number (and
UID?) into the CONVERTERROR like so:
 
      C: b004 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) BINARY[3]
      S: * 4 CONVERTED (TAG "b004") (BINARY[3] {2135}
          <the document in text/plain format with us-ascii
           character set>
         )
      S: * 5 CONVERTERROR (TAG "b004") (BADPARAMETERS 
            text/html text/plain ("charset" "us-ascii"))
            Source text has non us-ascii
      S: b004 OK Curates egg

But this does not work well for the more complicated case where there are
several bodyparts to convert, and some succeed and some fail for a given
message.  The convert error is not specific to the command, nor to a particular
message, but a particular body part.  My next action was to consider the FETCH
command, and what it does when information is unavailable: it returns NIL.
Perhaps we should consider the CONVERTERROR a "fat NIL".  This gets a little
verbose, but is at least consistent:
 
      C: b005 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) 
                 BINARY[2] BINARY[3]
      S: * 4 CONVERTED (TAG "b005") (
         BINARY[2] {2135}
          <the document in text/plain format with us-ascii
           character set>
         BINARY[3] (CONVERTERROR (BADPARAMETERS text/html text/plain 
          ("charset" "us-ascii")) Source text has non us-ascii))
      S: * 5 CONVERTED (TAG "b005") (
         BINARY[3] (CONVERTERROR (BADPARAMETERS text/html text/plain
          ("charset" "us-ascii")) Source text has non us-ascii)
         BINARY[2] {2135}
          <the document in text/plain format with us-ascii
           character set>)
      S: b005 OK Curates egg

(msgno 4 part 2 and msgno 5 part 3 are successfully converted, msgno 4 part 3
and msgno 3 part 2 errored).

This looks promising, but we are not done yet.  Supposing the command had
requested BODYPARTSTRUTURE as well as BINARY for each conversion.  What does
this new scheme return?

      C: b003 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) 
                 BODYPARTSTUCTURE[2] BINARY[2] 
                 BODYPARTSTUCTURE[3] BINARY[3]
      S: * 4 CONVERTED (TAG "b005") (
          BODYPARTSTRUCTURE[2] ("TEXT" "PLAIN" (CHARSET "US-ASCII")
                                 NIL NIL "8bit" 2135 NIL NIL NIL)
          BINARY[2] {2135}
          <the document in text/plain format with us-ascii
           character set>
          BODYPARTSTRUCTURE[3] (CONVERTERROR (BADPARAMETERS 
           text/html text/plain ("charset" "us-ascii")) 
           Source text has non us-ascii)
          BINARY[3] (CONVERTERROR (BADPARAMETERS
           text/html text/plain ("charset" "us-ascii"))
           Source text has non us-ascii))
      S: * 5 CONVERTED (TAG "b005") (
          BODYPARTSTRUCTURE[2] (CONVERTERROR (BADPARAMETERS
           text/html text/plain ("charset" "us-ascii"))
           Source text has non us-ascii)
          BINARY[2] (CONVERTERROR (BADPARAMETERS
           text/html text/plain ("charset" "us-ascii"))
           Source text has non us-ascii)
          BODYPARTSTRUCTURE[2] ("TEXT" "PLAIN" (CHARSET "US-ASCII")
                                 NIL NIL "8bit" 2135 NIL NIL NIL)
          BINARY[3] {2135}
          <the document in text/plain format with us-ascii
           character set>))
      S: b005 OK Curates egg

The command sends an untagged CONVERTED response for each message, and either
the requested data or an error response to each item requested.  But this does
end up with duplicated error messages going back to the client.  Perhaps we can
do better.  Suppose instead of sending back the specific data items with the
CONVERTERROR objects, we send back just the CONVERTERROR:

      C: b003 CONVERT 4:5 ("text/plain" ("charset" "us-ascii")) 
                 BODYPARTSTUCTURE[2] BINARY[2] 
                 BODYPARTSTUCTURE[3] BINARY[3]
      S: * 4 CONVERTED (TAG "b005") (
          BODYPARTSTRUCTURE[2] ("TEXT" "PLAIN" (CHARSET "US-ASCII")
                                 NIL NIL "8bit" 2135 NIL NIL NIL)
          BINARY[2] {2135}
          <the document in text/plain format with us-ascii
           character set>
          CONVERTERROR[3] ((BADPARAMETERS 
           text/html text/plain ("charset" "us-ascii")) 
           Source text has non us-ascii))
      S: * 5 CONVERTED (TAG "b005") (
          CONVERTERROR[2] ((BADPARAMETERS
           text/html text/plain ("charset" "us-ascii"))
           Source text has non us-ascii)
          BODYPARTSTRUCTURE[2] ("TEXT" "PLAIN" (CHARSET "US-ASCII")
                                 NIL NIL "8bit" 2135 NIL NIL NIL)
          BINARY[3] {2135}
          <the document in text/plain format with us-ascii
           character set>))
      S: b005 OK Curates egg

This feels better, but it may pose problems for clients to parse, and I am a
server person rather than a client person.

I think I have identified a problem and put forward two candidate solutions.  I
favour the second, but others my feel otherwise or have a quite different take
on the whole problem.

Peter

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