Subject: Re: content-type and name parameter
From: Peter Koch <[email-masked]>
To: [email-masked]
Date: Tue, 13 Dec 2005 17:09:37 +0100
List-Id: <ietf-822.imc.org>

Francesco Gennai wrote:

> P.s.: technically speaking, I would avoid the name "attachment", because I 
> think that we should speak simply of MIME parts, but I noticed that some 
> RFC (after the MIME ones) refers to the word "attachment" to indicate a 
> message part.

this is going off topic, but i'm glad someone brings this up. I agree w.r.t.
IETF documents, while you can't control the language used by end users.
And as you said, even mail related RFCs (e.g. 2060) have been using this term
for years, with no or only a fuzzy definition.

> Should be such RFC amended ? Should the RFC editors pay more attention
> on such terminology ? 

Not sure who exactly who should be the guard here, but it's a problem withh the
review and sometimes with different communities using different "language".
With so many drafts to review, these alleged nitpicking issues tend to fall
apart. There are other examples, e.g. "DNS" being falsely expanded to
Domain Name Service. Next time you see this kind of wording in a draft,
try to convince the author/editor.
To be continued on rfc-interest ...

-Peter

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: content-type and name parameter
Date:  Fri, 09 Dec 2005 19:40:52 +0100
Organization:  <URL:http://purl.net/xyzzy>
Lines: 15
Sender: [email-masked]

Francesco Gennai wrote:

> I wonder if there is any client (desktop client for Windows,
> Mac, etc..) that doesn't include the name parameter when
> creating a content-type.

My client adds a redundant name="x" to the Content-Type if and
only if there's also a filename="x" for a Content-Disposition:
attachment.

For Content-Disposition: inline it sometimes (e.g. text/html)
also adds a filename="x", and then it again copies this as a
name="x" to the Content-Type.
                              Bye, Frank

Date: Fri, 09 Dec 2005 18:53:29 +0100
From: Francesco Gennai <[email-masked]>
Subject: Re: content-type and name parameter
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Ned,
thank you a lot for your clear and helpful answer.

You wrote:
> not file name information. Clients that depend on file name information
> for this are egregiously broken. Sadly, there are many such clients, and
> they contribute substantially to ongoing security problems for email.

More sadly, in Italy, we have an e-mail service (it is based on technical rules 
pubblished as law) where the server rely on such parameters (name or filename) 
to recognizes an attachment in a multipart message.

Could you send me the name of the e-mail client that you are using ?   
You can send it off-list, if you prefer.

Thank you !
Francesco
P.s.: technically speaking, I would avoid the name "attachment", because I 
think that we should speak simply of MIME parts, but I noticed that some 
RFC (after the MIME ones) refers to the word "attachment" to indicate a 
message part.
I think that this can cause a bit of confusion.
Should be such RFC amended ? Should the RFC editors pay more attention
on such terminology ? 

> > I have a question about the use of name parameter in MIME header content-type.

> > Such parameter is optional in most of the media types,

> It is deprecated, not optional. See RFC 2046 section 4.5.1. Software doesn't
> have to generate this field to transfer filename information and must certainly
> should not be using this value to control any aspect of processing.

> The correct place to put file name information is in the filename parameter
> on the content-disposition line. But even this field is optional - you cannot
> rely on it being there. In many cases including the filename is totally
> inappropriate.

> > and
> > (correct me if I'm wrong) it's optional for application/msword,
> > application/pdf and similar media types.

> It doesn't matter what the specific media type is: It is deprecated in all
> cases.

> > Also if it is optional it seems that most of desktop e-mail clients
> > include it when generating one of such content-type.

> Good ones will at most generqate this field in addition to putting the filename
> in the content-disposition line. And even that is probably no longer a very
> good idea.

> > So I wonder if there is any client (desktop client for Windows, Mac, etc..)
> > that doesn't include the name parameter when creating a content-type.

> Well, the client I'm using right now does. I wouldn't use a client that
> includes file names by default, in any field whatsoever.

> > Could someone rely on the presence of such parameter to develop some software ?
> > I think no, but your opinion is very much important for me.

> Absolutely not. You cannot rely on ANY sort of filename information being
> present in the header. MIME uses media type information to control processing,
> not file name information. Clients that depend on file name information
> for this are egregiously broken. Sadly, there are many such clients, and
> they contribute substantially to ongoing security problems for email.

> In the cases where the file name is useful it should be carried in the
> content-disposition field as a filename parameter. Placing the information in a
> name parameter on the content-type is at best a sop to broken clients.

> 				Ned

From: [email-masked]
Cc: [email-masked]
To: Francesco Gennai <[email-masked]>
Date: Fri, 09 Dec 2005 09:32:47 -0800 (PST)
Subject: Re: content-type and name parameter
Sender: [email-masked]

> I have a question about the use of name parameter in MIME header content-type.

> Such parameter is optional in most of the media types,

It is deprecated, not optional. See RFC 2046 section 4.5.1. Software doesn't
have to generate this field to transfer filename information and must certainly
should not be using this value to control any aspect of processing.

The correct place to put file name information is in the filename parameter 
on the content-disposition line. But even this field is optional - you cannot
rely on it being there. In many cases including the filename is totally
inappropriate.

> and
> (correct me if I'm wrong) it's optional for application/msword,
> application/pdf and similar media types.

It doesn't matter what the specific media type is: It is deprecated in all
cases.

> Also if it is optional it seems that most of desktop e-mail clients
> include it when generating one of such content-type.

Good ones will at most generqate this field in addition to putting the filename
in the content-disposition line. And even that is probably no longer a very
good idea.

> So I wonder if there is any client (desktop client for Windows, Mac, etc..)
> that doesn't include the name parameter when creating a content-type.

Well, the client I'm using right now does. I wouldn't use a client that
includes file names by default, in any field whatsoever.

> Could someone rely on the presence of such parameter to develop some software ?
> I think no, but your opinion is very much important for me.

Absolutely not. You cannot rely on ANY sort of filename information being
present in the header. MIME uses media type information to control processing,
not file name information. Clients that depend on file name information
for this are egregiously broken. Sadly, there are many such clients, and 
they contribute substantially to ongoing security problems for email.

In the cases where the file name is useful it should be carried in the
content-disposition field as a filename parameter. Placing the information in a
name parameter on the content-type is at best a sop to broken clients.

				Ned

From: Ingo =?iso-8859-1?q?Kl=F6cker?= <[email-masked]>
To: [email-masked]
Subject: Re: content-type and name parameter
Date: Fri, 9 Dec 2005 17:35:49 +0100
Sender: [email-masked]

--nextPart8732676.hoHGt61pbk
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 09 December 2005 09:13, Francesco Gennai wrote:
> I have a question about the use of name parameter in MIME header
> content-type.
>
> Such parameter is optional in most of the media types, and
> (correct me if I'm wrong) it's optional for application/msword,
> application/pdf and similar media types.
>
> Also if it is optional it seems that most of desktop e-mail clients
> include it when generating one of such content-type.
>
> So I wonder if there is any client (desktop client for Windows, Mac,
> etc..) that doesn't include the name parameter when creating a
> content-type.
>
> Could someone rely on the presence of such parameter to develop some
> software ? I think no, but your opinion is very much important for
> me.

You can never rely on anything when you process email. Always remember:=20
"Be strict when sending and tolerant when receiving." (RFC 1958, 3.9)

Regards,
Ingo (maintainer of KMail)

--nextPart8732676.hoHGt61pbk
Content-Type: application/pgp-signature

--nextPart8732676.hoHGt61pbk--

Date: Fri, 09 Dec 2005 09:13:15 +0100
From: Francesco Gennai <[email-masked]>
Subject: content-type and name parameter
To: [email-masked]
Sender: [email-masked]

I have a question about the use of name parameter in MIME header content-type.

Such parameter is optional in most of the media types, and
(correct me if I'm wrong) it's optional for application/msword,
application/pdf and similar media types.

Also if it is optional it seems that most of desktop e-mail clients 
include it when generating one of such content-type.

So I wonder if there is any client (desktop client for Windows, Mac, etc..)
that doesn't include the name parameter when creating a content-type.

Could someone rely on the presence of such parameter to develop some software ?
I think no, but your opinion is very much important for me.

Thank you,
/Francesco