Subject: [lemonade] RE: CONVERT draft and headers

From: Peter Coates <[email-masked]>
Date: Tue, 11 Dec 2007 20:13:42 -0800

Presumably convert body(header) should support RFC 2231 as well as RFC 2047.
That is actually a much harder problem especially to handle the

    title*0*=us-ascii'en'This%20is%20even%20more%20

    title*1*=%2A%2A%2Afun%2A%2A%2A%20

    title*2="isn't it!"

variant.  In general these need putting together and taking apart again.  We
can not trust that there isn't a break in the middle of some escape sequence
or some such foolishness.  And when breaking the resulting UTF-8 into
chunks, we ought to be careful not to repeat the foolishness by breaking
UTF-8 is daft places.

I believe that we should be processing 2047 encoded words wherever we find
them, even if they are in places where there are not supposed to be encoded
words: they were probably put there by a broken client. that is far more
likely than something looking like an encoded word by accident.  And there
is the 2231 variant of 2047 encoded words to handle.  But the 2231
parameters are more difficult.  We should only look for then in the correct
places: content-type and content-disposition fields (anywhere else?).

Peter

From: Peter Coates [mailto:[email-masked]] 
Sent: December 11, 2007 16:41
To: [email-masked]'
Subject: CONVERT draft and headers

The CONVERT command gives clients with knowledge only of UTF-8 the ability
to retrieve text message parts converted into UTF-8.  But there is no
mechanism for such clients to ask the server to deal with headers with weird
encoded words.  I propose that the CONVERT command be augmented so that
commands of the form

Xa convert 83 (NIL) body[header]

Xb convert 83 (NIL) body[1.header]

Have the expected result of returning the requested headers with encoded
words replace with utf-8 encoded words.

We could go further as support

Xc convert 83 (NIL (charset foo)) body[header]

But I see little point.

WHY, you ask, am I suggestion replacing weird encoded words with UTF-8
encoded words rather than just returning the headers in UTF-8.  Well, the
answer is that encoded words occur in structured headers, and act as a
quoting mechanism.  It is hideously difficult to requite such a string
correctly.  Things like addresses in To: headers still need to be teased
apart by clients, so the output of the convert has to be parsable.

Please comment.  The requirement to convert headers is obvious.  That this
is a solution is clear.  That it is the best solution is not yet clear to me
(although I have implemented it).

Peter

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