I have made a revision to the current C-D draft. Before submitting the
full revision, I want to run the salient bits by everyone. If these
changes are largely acceptable, I will submit a new draft.
Regarding absent C-D (change):
Content-Disposition is an optional header; in its absence,
the MUA may use whatever presentation method it deems
suitable.
To the grammar (removed quoted-phrase):
disposition := "Content-Disposition" ":"
disposition-type
*(";" disposition-parm)
disposition-type := "inline"
/ "attachment"
/ extension-token
; values are not case-sensitive
disposition-parm := filename-parm / parameter
filename-parm := "filename" "=" value;
`Extension-token', `parameter' and `value' are defined
according to [RFC 822] and [RFC 1521].
Regarding how the filename is to be used (change):
The sender may want to suggest a filename to be used if the
entity is detached and stored in a separate file. If the
receiving MUA writes the entity to a file, the suggested
filename should be used as a basis for the actual filename,
where possible.
It is important that the receiving MUA not simply blindly use
the suggested filename. The suggested filename should be
checked (and possibly changed) to see that it conforms to
local filesystem conventions, does not overwrite an existing
file, and does not present a security problem (see Security
Considerations below).
Regarding directory paths (addition):
The receiving MUA should not respect any directory path
information that may seem to be present in the filename
parameter. The filename should be treated as a terminal
component only. Portable specification of directory paths
might possibly be done in the future via a separate Content-
Disposition parameter, but no provision is made for it in
this draft.
Regarding non-US-ASCII characters (punt):
Current [RFC 1521] grammar restricts parameter values (and
hence Content-Disposition filenames) to US-ASCII. We
recognize the great desirability of allowing arbitrary
character sets in filenames, but it is beyond the scope of
this document to define the necessary mechanisms. We expect
that the basic [RFC 1521] `value' specification will someday
be amended to allow use of non-US-ASCII characters, at which
time the same mechanism should be used in the Content-
Disposition filename parameter.
Regarding portable filenames (addition):
Beyond the limitation to US-ASCII, the sending MUA may wish
to bear in mind the limitations of common filesystems. Many
have severe length and character set restrictions. Short
alphanumeric filenames are most likely not to require
modification by the receiving system.
Regarding the "scope" of parameters (addition):
Unless noted otherwise in the definition of a parameter,
Content-Disposition parameters are valid for all
dispositions. (In contrast to [RFC 1521] content-type
parameters, which are defined on a per-content-type basis.)
Thus, for example, the `filename' parameter always means the
name of the file to which the part should be written, even if
the disposition itself is unrecognized.
Regarding the main message (change):
3.6 Content-Disposition and the Main Message
It is permissible to use Content-Disposition on the main body
of an [RFC 822] message.
(Language regarding weirdness of inline/attachment on main body removed.)
Regarding security considerations (addition):
It is very important to note that this is not an exhaustive
list; it is intended as a small set of examples only.
Implementors must be alert to the potential hazards on their
target systems.
(A few people have suggested that many more examples of security hazards be
included, for UNIX and for other operating systems. I am reluctant to do
this. I think it's hopeless to try to come up with an exhaustive catalog
of hazards for all operating systems. The more the examples in the RFC look
like such a catalog, the more people will be tempted to treat it as such.
I prefer to be clear that the RFC contains a few examples only, and is no
substitute for careful thought and design on their part.)
--
Steve Dorner, Qualcomm Incorporated. "Oog make mission statement."