- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 29 Mar 2008 13:34:26 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote:
>
> On 29/03/2008, at 6:17 AM, Julian Reschke wrote:
>>
>>
>>> * p1, 2.2:
>>> Old:
>>>> comment = "(" *( ctext | quoted-pair | comment ) ")"
>>> New:
>>> """
>>> comment = "(" *( ctext | quoted-pair | comment | encoded-word ) ")"
>>> """
>>
>> OK, but then we'll have to state somewhere where encoded-word comes
>> from; <http://tools.ietf.org/html/rfc2047#section-2>?
>>
>> Also, do we really Really REALLY want to require to support all what's
>> in there?
>
> Any specific thoughts? It's already been suggested that the charsets
> available be limited... anything else?
Section 4 defines two different encodings; are they both needed?
>>> * p3, B.1:
>>> Old:
>>>> filename-parm = "filename" "=" quoted-string
>>> New:
>>> """
>>> filename-parm = "filename" "=" quoted-string | encoded-word
>>> """
>>
>> I'd prefer to make C-D a special case where we specify *exactly*
>> what's needed, nothing more (which means: RFC2231 encoding of utf-8,
>> no line folding/contiuation lines).
>
> Why not make that the case for all uses of encoded-word? The most
> effective way to clarify this might be to mint a new rule which defines
> itself by refining the definition of encoded-word, with the appropriate
> references and caveats.
Good point.
In my experience, the filename parameter in C-D actually is the single
place where I18N really is used in *practice*. Unfortunately, out of the
four major UAs, only two do it correctly.
BR, Julian
Received on Saturday, 29 March 2008 12:35:23 UTC