As per Relevance of the word filename, we have this rfc below:
Network Working Group R.
Request for Comments: 1806 New Century
Category: Experimental S.
QUALCOMM
June 1995
Communicating Presentation Information
Internet Messages
The Content-Disposition
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
This memo provides a mechanism whereby messages conforming to
[RFC 1521] ("MIME") specification can convey
information. It specifies a new "Content-Disposition" header
optional and valid for any [RFC 1521] entity ("message" or "
part"). Two values for this header are described in this memo;
for the ordinary linear presentation of the body part, and another
facilitate the use of mail to transfer files. It is expected
more values will be defined in the future, and procedures are
for extending this set of values
This document is intended as an extension to [RFC 1521]. As such,
reader is assumed to be familiar with [RFC 1521], and [RFC 822].
information presented herein supplements but does not replace
found in those documents
1.
[RFC 1521] specifies a standard format for encapsulating
pieces of data into a single Internet message. That document does
address the issue of presentation styles; it provides a framework
the interchange of message content, but leaves presentation
solely in the hands of mail user agent (MUA) implementors
Two common ways of presenting multipart electronic messages are as
main document with a list of separate attachments, and as a
document with the various parts expanded (displayed) inline.
display of an attachment is generally construed to require
action on the part of the recipient, while inline message
Troost & Dorner Experimental [Page 1]
RFC 1806 Content-Disposition June 1995
are displayed automatically when the message is viewed. A
is needed to allow the sender to transmit this sort of
information to the recipient; the Content-Disposition header
this mechanism, allowing each component of a message to be
with an indication of its desired presentation semantics
Tagging messages in this manner will often be sufficient for
message formatting. However, in many cases a more powerful
flexible approach will be necessary. The definition of
approaches is beyond the scope of this memo; however, such
can benefit from additional Content-Disposition values
parameters, to be defined at a later date
In addition to allowing the sender to specify the
disposition of a message component, it is desirable to allow her
indicate a default archival disposition; a filename. The
"filename" parameter provides for this
2. The Content-Disposition Header
Content-Disposition is an optional header; in its absence, the
may use whatever presentation method it deems suitable
It is desirable to keep the set of possible disposition types
and well defined, to avoid needless complexity. Even so,
usage will likely require the definition of additional
types or parameters, so the set of disposition values is extensible
see below
In the extended BNF notation of [RFC 822], the Content-
header field is defined as follows
disposition := "Content-Disposition" ":"
disposition-
*(";" disposition-parm
disposition-type := "inline
/ "attachment
/ extension-
; values are not case-
disposition-parm := filename-parm /
filename-parm := "filename" "=" value
`Extension-token', `parameter' and `value' are defined according
[RFC 822] and [RFC 1521].
Troost & Dorner Experimental [Page 2]
RFC 1806 Content-Disposition June 1995
2.1 The Inline Disposition
A bodypart should be marked `inline' if it is intended to
displayed automatically upon display of the message. Inline
should be presented in the order in which they occur, subject to
normal semantics of multipart messages
2.2 The Attachment Disposition
Bodyparts can be designated `attachment' to indicate that they
separate from the main body of the mail message, and that
display should not be automatic, but contingent upon some
action of the user. The MUA might instead present the user of
bitmap terminal with an iconic representation of the attachments, or
on character terminals, with a list of attachments from which
user could select for viewing or storage
2.3 The Filename
The sender may want to suggest a filename to be used if the entity
detached and stored in a separate file. If the receiving MUA
the entity to a file, the suggested filename should be used as
basis for the actual filename, where possible
It is important that the receiving MUA not blindly use the
filename. The suggested filename should be checked (and
changed) to see that it conforms to local filesystem conventions
does not overwrite an existing file, and does not present a
problem (see Security Considerations below).
The receiving MUA should not respect any directory path
that may seem to be present in the filename parameter. The
should be treated as a terminal component only.
specification of directory paths might possibly be done in the
via a separate Content-Disposition parameter, but no provision
made for it in this draft
Current [RFC 1521] grammar restricts parameter values (and
Content-Disposition filenames) to US-ASCII. We recognize the
desirability of allowing arbitrary character sets in filenames,
it is beyond the scope of this document to define the
mechanisms. We expect that the basic [RFC 1521] `value
specification will someday be amended to allow use of non-US-
characters, at which time the same mechanism should be used in
Content-Disposition filename parameter
Troost & Dorner Experimental [Page 3]
RFC 1806 Content-Disposition June 1995
Beyond the limitation to US-ASCII, the sending MUA may wish to
in mind the limitations of common filesystems. Many have
length and character set restrictions. Short alphanumeric
are least likely to require modification by the receiving system
The presence of the filename parameter does not force
implementation to write the entity to a separate file. It
perfectly acceptable for implementations to leave the entity as
of the normal mail stream unless the user requests otherwise. As
consequence, the parameter may be used on any MIME entity,
`inline' ones. These will not normally be written to files, but
parameter could be used to provide a filename if the receiving
should choose to write the part to a file
2.4 Future Extensions and Unrecognized Disposition
In the likely event that new parameters or disposition types
needed, they should be registered with the IANA, in the
specified in [RFC 1521], appendix E
Once new disposition types and parameters are defined, there is
course the likelihood that implementations will see disposition
and parameters they do not understand. Furthermore, since x-
are allowed, implementations may also see entirely
disposition types and parameters
Unrecognized parameters should be ignored. Unrecognized
types should be treated as `attachment'. The choice of `attachment
for unrecognized types is made because a sender who goes to
trouble of producing a Content-Disposition header with a
disposition type is more likely aiming for something more
than inline presentation
Unless noted otherwise in the definition of a parameter, Content
Disposition parameters are valid for all dispositions. (In
to [RFC 1521] content-type parameters, which are defined on a per
content-type basis.) Thus, for example, the `filename'
still means the name of the file to which the part should be written
even if the disposition itself is unrecognized
2.5 Content-Disposition and
If a Content-Disposition header is used on a multipart body part,
applies to the multipart as a whole, not the individual subparts
The disposition types of the subparts do not need to be
until the multipart itself is presented. When the multipart
displayed, then the dispositions of the subparts should be respected
Troost & Dorner Experimental [Page 4]
RFC 1806 Content-Disposition June 1995
If the `inline' disposition is used, the multipart should
displayed as normal; however, an `attachment' subpart should
action from the user to display
If the `attachment' disposition is used, presentation of
multipart should not proceed without explicit user action. Once
user has chosen to display the multipart, the individual
dispositions should be consulted to determine how to present
subparts
2.6 Content-Disposition and the Main
It is permissible to use Content-Disposition on the main body of
[RFC 822] message
3.
Here is a an example of a body part containing a JPEG image that
intended to be viewed by the user immediately
Content-Type: image/
Content-Disposition:
Content-Description: just a small picture of
The following body part contains a JPEG image that should
displayed to the user only if the user requests it. If the JPEG
written to a file, the file should be named "genome.jpg":
Content-Type: image/
Content-Disposition: attachment; filename=genome.
Content-Description: a complete map of the human
The following is an example of the use of the `attachment
disposition with a multipart body part. The user should see text
part-1 immediately, then take some action to view multipart-2.
taking action to view multipart-2, the user will see text-part-2
right away, and be required to take action to view jpeg-1.
are indented for clarity; they would not be so indented in a
message
Content-Type: multipart/mixed; boundary=
Content-Description: multipart-1
--
Troost & Dorner Experimental [Page 5]
RFC 1806 Content-Disposition June 1995
Content-Type: text/
Content-Disposition:
Content-Description: text-part-1
Some text goes
--
Content-Type: multipart/mixed; boundary=
Content-Disposition:
Content-Description: multipart-2
--
Content-Type: text/
Content-Disposition:
Content-Description: text-part-2
Some more text here
--
Content-Type: image/
Content-Disposition:
Content-Description: jpeg-1
--inner--
--outer--
4.
Content-Disposition takes one of two values, `inline'
`attachment'. 'Inline' indicates that the entity should
immediately displayed to the user, whereas `attachment' means
the user should take additional action to view the entity
The `filename' parameter can be used to suggest a filename
storing the bodypart, if the user wishes to store it in an
file
5. Security
There are security issues involved any time users exchange data
While these are not to be minimized, neither does this memo
the status quo in that regard, except in one instance
Since this memo provides a way for the sender to suggest a filename
a receiving MUA must take care that the sender's suggested
does not represent a hazard. Using UNIX as an example, some
would be
Troost & Dorner Experimental [Page 6]
RFC 1806 Content-Disposition June 1995
+ Creating startup files (e.g., ".login").
+ Creating or overwriting system files (e.g.,
"/etc/passwd").
+ Overwriting any existing file
+ Placing executable files into any command search
(e.g., "~/bin/more").
+ Sending the file to a pipe (e.g., "| sh").
In general, the receiving MUA should never name or place the
such that it will get interpreted or executed without the
explicitly initiating the action
It is very important to note that this is not an exhaustive list;
is intended as a small set of examples only. Implementors must
alert to the potential hazards on their target systems
6.
[RFC 1521]
Borenstein N., and N. Freed, "MIME (Multipurpose
Mail Extensions) Part One: Mechanisms for Specifying
Describing the Format of Internet Message Bodies",
RFC 1521, Bellcore, Innosoft, September 1993.
[RFC 822]
Crocker, D., "Standard for the Format of ARPA
Text Messages", STD 11, RFC 822, UDEL, August 1982.
7.
We gratefully acknowledge the help these people
during the preparation of this draft
Nathaniel
Ned
Keith
Dave
Dan
Troost & Dorner Experimental [Page 7]
RFC 1806 Content-Disposition June 1995
8. Authors'
Rens
New Century
324 East 41st Street #804
New York, NY, 10017
Phone: +1 (212) 557-2050
Fax: +1 (212) 557-2049
EMail: rens@century.
Steve
QUALCOMM
6455 Lusk
San Diego, CA 92121
EMail: sdorner@qualcomm.
Troost & Dorner Experimental [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
