Long MIME media type or disposition parameter values do not interact
   well with header line wrapping conventions.  In particular, proper
   header line wrapping depends on there being places where linear
   whitespace (LWSP) is allowed, which may or may not be present in a
   parameter value, and even if present may not be recognizable as such
   since specific knowledge of parameter value syntax may not be
   available to the agent doing the line wrapping. The result is that
   long parameter values may end up getting truncated or otherwise
   damaged by incorrect line wrapping implementations.

   A mechanism is therefore needed to break up parameter values into
   smaller units that are amenable to line wrapping. Any such mechanism
   MUST be compatible with existing MIME processors. This means that

(1) the mechanism MUST NOT change the syntax of MIME media type and disposition lines, and

(1) 方法は MIME 媒体型及び意向行の構文を変えてはならない。

(2) the mechanism MUST NOT depend on parameter ordering since MIME states that parameters are not order sensitive. Note that while MIME does prohibit modification of MIME headers during transport, it is still possible that parameters will be reordered when user agent level processing is done.

(2) 方法は parameter 順に依存してはならない。 MIME はパラメーターの順は関係しないとしている。 なお、 MIME は転送中の MIME 頭の編集は禁止しているので、 利用者代理者段階の処理が行われた時にパラメーターの順序を 変えることは可能ではある。

   The obvious solution, then, is to use multiple parameters to contain
   a single parameter value and to use some kind of distinguished name
   to indicate when this is being done.  And this obvious solution is
   exactly what is specified here: The asterisk character ("*") followed
   by a decimal count is employed to indicate that multiple parameters
   are being used to encapsulate a single parameter value.  The count
   starts at 0 and increments by 1 for each subsequent section of the
   parameter value.  Decimal values are used and neither leading zeroes
   nor gaps in the sequence are allowed.

The original parameter value is recovered by concatenating the various sections of the parameter, in order. For example, the content-type field

元のパラメーター値はパラメーターの各節を順につなぐことで復元されます。 例えば次の content-type 領域

        Content-Type: message/external-body; access-type=URL;
         URL*0="ftp://";
         URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

is semantically identical to

は意味的には次のものと同じです。

        Content-Type: message/external-body; access-type=URL;
          URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

Note that quotes around parameter values are part of the value syntax; they are NOT part of the value itself. Furthermore, it is explicitly permitted to have a mixture of quoted and unquoted continuation fields.

なお、 parameter value の周りの引用符は value 構文の一部ではありません。 これは value の一部ではないのです。なお、引用符で囲まれている継続領域 と囲まれていない継続領域が混じっていることは明確に認められます。

   Some parameter values may need to be qualified with character set or
   language information.  It is clear that a distinguished parameter
   name is needed to identify when this information is present along
   with a specific syntax for the information in the value itself.  In
   addition, a lightweight encoding mechanism is needed to accommodate 8
   bit information in parameter values.

   Asterisks ("*") are reused to provide the indicator that language and
   character set information is present and encoding is being used. A
   single quote ("'") is used to delimit the character set and language
   information at the beginning of the parameter value. Percent signs
   ("%") are used as the encoding flag, which agrees with RFC 2047.

   Specifically, an asterisk at the end of a parameter name acts as an
   indicator that character set and language information may appear at
   the beginning of the parameter value. A single quote is used to
   separate the character set, language, and actual value information in
   the parameter value string, and an percent sign is used to flag
   octets encoded in hexadecimal.  For example:

        Content-Type: application/x-stuff;
         title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

   Note that it is perfectly permissible to leave either the character
   set or language field blank.  Note also that the single quote
   delimiters MUST be present even when one of the field values is
   omitted.  This is done when either character set, language, or both
   are not relevant to the parameter value at hand.  This MUST NOT be
   done in order to indicate a default character set or language --
   parameter field definitions MUST NOT assign a default character set
   or language.

   Content-Type: application/x-stuff
    title*0*=us-ascii'en'This%20is%20even%20more%20
    title*1*=%2A%2A%2Afun%2A%2A%2A%20
    title*2="isn't it!"

IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations when generating the BODY and BODYSTRUCTURE fetch attributes.

The ABNF for MIME parameter values given in RFC 2045 is:

RFC 2045 で MIME パラメーター値の ABNF は

   parameter := attribute "=" value

   attribute := token
                ; Matching of attributes
                ; is ALWAYS case-insensitive.

This specification changes this ABNF to:

でした。この仕様書はこの ABNF を次のように変更します。

   parameter := regular-parameter / extended-parameter

   regular-parameter := regular-parameter-name "=" value

   regular-parameter-name := attribute [section]

   attribute := 1*attribute-char

   attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs,
                     "*", "'", "%", or tspecials>

   section := initial-section / other-sections

   initial-section := "*0"

   other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
                          "6" / "7" / "8" / "9") *DIGIT)

   extended-parameter := (extended-initial-name "="
                          extended-value) /
                         (extended-other-names "="
                          extended-other-values)

; 編註: extened-value は extended-initial-value の誤り?

   extended-initial-name := attribute [initial-section] "*"

   extended-other-names := attribute other-sections "*"

   extended-initial-value := [charset] "'" [language] "'"
                             extended-other-values

   extended-other-values := *(ext-octet / attribute-char)

   ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")

   charset := <registered character set name>

   language := <registered language tag [RFC-1766]>

(以下略)

RFC 5987 が各最新ブラウザで問題なくファイル名指定ダウンロードができることが分かりました。エンコード方法によっては400エラーになってしまったり、ファイル名が正しく指定できなかったりとサポートしていないことが分かります。