headers
Francesco Gennai | 9 Dec 09:13
Picon

content-type and name parameter


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
Permalink | Reply | 5 comments |
headers
Ingo Klöcker | 9 Dec 17:35
Picon
Favicon

Re: content-type and name parameter

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: 
"Be strict when sending and tolerant when receiving." (RFC 1958, 3.9)

Regards,
Ingo (maintainer of KMail)
Permalink | Reply | 0 comments |
headers
ned+ietf-822 | 9 Dec 18:32

Re: content-type and name parameter


> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francesco Gennai | 9 Dec 18:53
Picon

Re: content-type and name parameter


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,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Ellermann | 9 Dec 19:40
Picon
Picon

Re: content-type and name parameter


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
Permalink | Reply | 0 comments |
headers
Peter Koch | 13 Dec 17:09
Picon
Picon

Re: content-type and name parameter


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
Permalink | Reply | 0 comments |

Gmane