Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07

[Alexey Melnikov <alexey.melnikov at isode.com>]

Hi Barry,

Barry Leiba wrote:

> pg 8/9
>
> There seems to be a conflict between these two paragraphs:
>
>   Server implementations also SHOULD up-convert all MIME body headers,
>   SHOULD up-convert or remove the deprecated (and misused) name
>   parameter [RFC1341] on Content-Type and MUST up-convert the Content-
>   Disposition filename parameter.  These parameters can be encoded
>   using the standard MIME parameter encoding [RFC2231] mechanism, or
>   via non-standard use of MIME header encoding [RFC2047] in quoted
>   strings.
>
>   The IMAP server MUST NOT perform up-conversion of headers and content
>   of multipart/signed, as well as Original-Recipient and Return-Path.
>
> Isn't it possible to have a subpart of a multipart/signed message that
> has a Content-Disposition header with a "filename" parameter?  If so,
> the first graph says you MUST up-convert it, and the second says you
> MUST NOT.
Right. I think the intent is for the second quoted paragraph to override 
the first.
So I think the first sentence of the first quoted paragraph should end 
with something like:

... and MUST up-convert the Content- Disposition filename parameter,
unless it is located inside a multipart/signed body part (see below).

> Also, I'd prefer putting the parameter names in quotes: "name"
> parameter ... "filename" parameter.
Yes, this would be better.
 [...]

> ----------------------------
>
> I note for the record that the reference to the obsolete RFC 1341 is
> intentional.  I wonder, though, whether it really ought to be
> normative.  Hm.
>  
It sounds normative. But I don't know if such parameters can be found in 
the wild in sufficient quantities to worry about anyway.