Subject: [lemonade] WGLC CONVERT

From: Eric Burger <[email-masked]>
Date: Tue, 18 Dec 2007 16:44:59 -0500

The work group last call for CONVERT ends 8 January 2008.  Please have at
it.

http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-13.txt

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

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

---

From: Dan Karp <[email-masked]>
Date: Tue, 18 Dec 2007 14:08:00 -0800 (PST)

> The work group last call for CONVERT ends 8 January 2008.  Please have
> at it.

   The client can request header convertions using the BODY[...HEADER]
   CONVERT request, for example

     C: D001 FETCH 2 BODY[HEADER]
     S: * 2 FETCH (BODY[HEADER] {152}
     S: Date: Mon, 20 Apr 2007 20:05:43 +0200
     S: From: peter <[email-masked]>
     S: To: Alexey <[email-masked]>
     S: Subject: =?USASCII*EN?Q?why encode this?=
     S:
     S: )
     S: D001 OK

     C: D002 CONVERT 2 (NIL ("CHARSET" "utf-8")) BODY[HEADER]
     S: * 2 CONVERTED (TAG "d002") (BODY[HEADER] {150}
     S: Date: Mon, 20 Apr 2007 20:05:43 +0200
     S: From: peter <[email-masked]>
     S: To: Alexey <[email-masked]>
     S: Subject: =?UTF-8*EN?Q?why encode this?=
     S:
     S: )
     S: D002 OK

Was there a copy/paste error here?  From the explanatory text, I'd expect the second Subject header to read "why encode this" without the 2047 encoding.

   The server ought to endeavour to preserver the headers during the
   conversion as much as possible.  But in a case like this, where
   characters are split (legally!) between fragments of an encoded
   parameter what is the server to do?  A safe answer is to 
   consolidate parameters that are in pieces, convert them and
   emit them fragmenting them again if necessary to keep the line
   length less than 78.  Comments embedded like this can be moved to
   after the parameter:

     C: D011 FETCH 3 BODY[1.MIME]
     S: * 3 FETCH (BODY[1.MIME] {118}
     S: Content-Type: text/plain; charset=utf-8;
     S:  foo*0*=utf-8'fr'tr%c0;
     S:  foo*1*(very)=%03s_m%c0;
     S:  foo*2*=(nasty)%09chant
     S:
     S: D011 OK

     C: D012 CONVERT 3 (NIL) BODY[1.MIME]
     S: * 3 CONVERTED (TAG "D012") (BODY[1.MIME] {109}
     S: Content-Type: text/plain; charset=utf-8;
     S:  foo*0*=utf-8'fr'tr%c0%03s_;
     S:  foo*1*=%m%c0%09chant (very)(nasty)
     S:
     S: D012 OK

Please leave it simple and explicitly allow servers to drop comments when transcoding headers.  (Also, I'm not sure that RFC 2231 actually allows comments in either of those places...)  We may also want to change the wording regarding 2231 encoding to flat-out state that

   Servers also SHOULD decode any parameters as described in [RFC2231],
   then re-encode the result in RFC 2231 format in the requested charset
   if necessary.

We should also include the expected transcoding behavior for messages that encode compound headers using the illegal-but-popular mechanism of RFC 2047 encoded-words inside quoted-strings.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Dec 2007 18:32:20 +0000

>>The work group last call for CONVERT ends 8 January 2008.  Please have
Hi Dan,
Thank you for your comments.

>Was there a copy/paste error here?
>
The example matches the current description, but ...

>From the explanatory text, I'd expect the second Subject header to read "why encode this" without the 2047 encoding.
>  
>
... this is a valid point and I think the text should be adjusted 
accordingly.

The example can also be changed to convert from ISO-8859-1 to UTF-8.

>Please leave it simple and explicitly allow servers to drop comments when transcoding headers.
>
That is fine with me. Suggest text?

>(Also, I'm not sure that RFC 2231 actually allows comments in either of those places...)  We may also want to change the wording regarding 2231 encoding to flat-out state that
>
If it is illegal according to RFC 2047, then we don't need to mention 
how to deal with them. GIGO.

---

From: Dan Karp <[email-masked]>
Date: Wed, 19 Dec 2007 11:12:36 -0800 (PST)

> > We should also include the expected transcoding behavior for messages
> > that encode compound headers using the illegal-but-popular mechanism
> > of RFC 2047 encoded-words inside quoted-strings.  
> 

A large percentage of past and current MUAs generate and parse that illegal
garbage, mainly because RFC 2231 support is still fairly rare.  Ignoring this
particular way of encoding strings in compound headers in the CONVERT draft
just ignores much of the non-ASCII mail out there.