Thank you Ned and Keith for the clear description. Francesco
> > Question about composing a MIME part where I would suggest > > also the file name. > > Question: > > In the case that I would suggest a file name to the remote > > MIME client could I use only the name parameter of the content-type > > or MUST I add the content-disposition header with the filename parameter? > The situation is as follows. The original MIME specifications only provided a > means to associated filenames with application/octet-stream parts. This was > done through the use of a name= parameter on the content-type. The theory here > was that filenames were mostly used for type information and therefore did not > need to be present in most cases. > This was a mistake on our part. It seems a lot of people really like to > associate file *names* with parts. So, when we didn't initially provide a > standard means to do this, people just started using name= parameters for all > sorts of different types. > Even worse was the presence of some agents that, in flagrant defiance of > MIME requirements, looked at file names for type information and ignored > the media type completely. > The specification of content-disposition attempted to provide a more general > means of providing file name information by defining a filename parameter as > part of the content-disposition field. Unfortunately in the process another > mistake was made: No name was defined for the nominal "default" disposition > that corresponds to no content-disosition being present. The result is that > the > now-standardized mechanism for associating a filename with a part cannot be > used without in some cases change the part semantics, since no > content-disposition isn't equivalent to inline , attachment or any other > disposition value. > So what are the operational implications of all this? There are several. One > is > that there are agents that only look at the name= parameter for filenames, and > other agents that only look at filename=. This in turn has led in some cases > to > attempts to bridge the gap by in effect copying the name= parameter value to > the filename= parameter value, either implicitly or explicitly. And that > behavior has the side effect that now the presence of a name= parameter can > effectively force a content-disposition setting onto a part. > So what should a generating agent do? The first thing to note is that > attempting to cater to any remaining agents that preferentially or exclusively > look to filenames for type information is an exercise in futility: Such agents > are deeply broken along several axes, the most important of which is security. > "Shoot on sight" is the only realistic answer here. > Beyond that I advocate restraint: If there's a way in your application to only > include filename information when it is absolutely necessary, use it. At a > minimum it will save embarassment when that proposal you just sent out doesn't > retain the filename "boondoggle.doc". > Finally, if you have to include filename information, either put it in a > filename= parameter or both a filename= and name= parameter. Never ever use > just a name= parameter because that opens you up to gratuitous interpretation > of the part using some disposition value you didn't intend. (I note in passing > that this is what Thunderbird now dows, with the added nuance of using > nonstandard RFC 2047 encoding for the name= paramter and standard RFC 2231 > encoding for the filename= parameter.) > > My doubt come also from the following sentence in RFC3851 > > (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 > > Message Specification): > > .. ..... . > > 3.2.1. The name and filename Parameters > > For the application/pkcs7-mime, sending agents SHOULD emit the > > optional "name" parameter to the Content-Type field for compatibility > > with older systems. Sending agents SHOULD also emit the optional > > Content-Disposition field [CONTDISP] with the "filename" parameter. > > If a sending agent emits the above parameters, the value of the > > parameters SHOULD be a file name with the appropriate extension: > > .... ..... ... > > where a system using only the name parameter is considered an "old system". > > So, I don't understand if "old system" is related to some old S/MIME > > system, or to a generic old MIME system.... > Unfortunately, given operational realities I would have to characterize this > as > somewhere between suboptimal and broken. > Ned
