Re: Issues-list item "DISPOSITION"

On Apr 22,  4:04am, Koen Holtman wrote:
> Subject: Issues-list item "DISPOSITION"
>
> Issues-list item "DISPOSITION"
>
> From the Memphis minutes:
>
> -- Content-Disposition will be added to the Appendix, as one
>    of a group of common MIME headers about which implementors should
>    be aware; Koen Holtman will draft the addition.
>
> Here is a draft of the addition.  This text is based on 1806 and on
> messages in the mailing list archive.  I have not tested this myself.
>
>
> 19.6.2.x Content-Disposition
>
>    The Content-Disposition response-header field has been proposed as
>    a means for the origin server to suggest a default filename if the
>    user requests that the content is saved to a file.  This usage is
>    derived from the definition of Content-Disposition in RFC 1806.
>
>         content-disposition = "Content-Disposition" ":"
>                               disposition-type *(";" disposition-parm)
>
>         disposition-type = "attachment" | disp-extension-token
>
>         disposition-parm = filename-parm | disp-extension-parm
>
>         filename-parm = "filename" "=" quoted-string
>
>         disp-extension-token = token
>
>         disp-extension-parm = token "=" ( token | quoted-string )
>
>    An example is
>
>         Content-Disposition: attachment; filename="fname.ext"
>
>    The receiving user agent 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.
>
>    If this header is used in a response with the
>    application/octet-stream content-type, the implied suggestion is
>    that the user agent should not display the response, but directly
>    enter a `save response as..'  dialog.
>
>
We still have a discrepancy on the delivered filename.  In general
the MUA tries to name the current stream based on the URI.  This leads to
unknown file types on the client system.  Based on messages in the archives,
maintainers are concerned that this will be compounded by groupware users and
others who want to share common files but the files are generated or retrieved
by an engine and not a straight URI.

>
[snip the security section]
>
> I'm not sure what we should do about these.  Should we repeat them in
> the security considerations section of 1.1, or is that not necessary?
>
IMHO, we should put these concerns in 1.1.  Since the MUA is acting our behalf,
shouldn't it obey a variant of the first law of robotics?

> Koen.
>
>-- End of excerpt from Koen Holtman


						Kevin
--
=============================================================================
Kevin J. Dyer					Draper Laboratory  MS 23.
Email: <kdyer@draper.com>		        555 Tech. Sq.
Phone: 617-258-4962				Cambridge, MA 02139
FAX: 617-258-2121
-----------------------------------------------------------------------------
   "Beware Geeks bearing GIFs"   Author Unknown
=============================================================================

Received on Tuesday, 22 April 1997 08:57:23 UTC