Hmmm. It seems like I'm taking a minority view alot here, but
someone has to I guess...
I think the concern that Nathaniel and Keith have are real and need
to be addressed, but the proposed solution is misplaced.
Are filenames-as-a-security problem real? Absolutely. Should
we address that problem by refusing to allow them into the spec?
Absolutely not.
Instead, we should note that this is fundamentally a UA issue.
For example, the UA could save to a filename if it doesn't
currently exist, and is below the users "folder" directory
tree, and only ask for confirmation if there is some sort of
conflict.
Another example is that of shell scripts and executables.
Originally, our UA did not allow their direct use. We got
an endless sequence of complaints, and eventually made them
work, but first put up an alert to the user pointing out the
pitfalls of running the script, and asking for a confirmation.
This seems to have been a good compromise between functionality
and security.
These are only examples. But hopefully rfc-xxxx will not take
the position that anything potentially dangerous should be prohibited;
instead it should allow those things that are genuinely useful
to be included, perhaps with an implementation note for people
designing user agents as to things they should be careful of
when implementing these features.
Both of the examples I gave (filenames and executables) are way
to useful to leave out of the spec because of a vague fear that
some user agents may do it wrong.
Neil
----- Begin Included Message -----