Subject: Re: [lemonade] WGLC CONVERT

From: Alexey Melnikov <[email-masked]>
Date: Sat, 19 Jan 2008 17:32:00 +0000

Alexey Melnikov wrote:

> Dan Karp wrote:
>
>>> The work group last call for CONVERT ends 8 January 2008.  Please have
>>> at it.
>>
> Hi Dan,
> Thank you for your comments.
>
>>   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?
>
> 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.

I've added:

 Note that encoded-words might not be needed if the result can be 
represented entirely in US-ASCII.

> The example can also be changed to convert from ISO-8859-1 to UTF-8.
>
>>   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.
>
> That is fine with me. Suggest text?

I've changed one sentence to read:

   Comments embedded like this SHOULD be moved after the parameter, but 
MAY be removed entirely.

Is this Ok with everybody?

>> (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
>

_______________________________________________
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: Sat, 19 Jan 2008 17:57:38 +0000

> Is this Ok with everybody?

I think the following is better:
    Comments embedded like this SHOULD be preserved
   during conversion, but MAY be removed entirely.  If they are
   preserved, they MAY be moved after the parameter.