[Top] [All Lists]

Content-Disposition changes

1995-01-18 17:11:22
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

To the grammar (removed quoted-phrase):

        disposition := "Content-Disposition" ":"
                       *(";" 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."

<Prev in Thread] Current Thread [Next in Thread>