Concerning autostart-spec

[Peter]

I have a concern about autoopen in the autostart-spec.  I'll start with
a quote:

The relative path MUST NOT point to an executable file. ... If the
relative path points to an executable file then the desktop environment
MUST NOT execute the file.

I don't know exactly how Windows-free you guys are, but consider if
someone wants a cross-platform medium of some kind.  They would
certainly want Windows to read it, and Windows formats often don't have
executable bits.  These mediums get mounted with EVERY file marked
executable, at least on every Unix (which pretty much means Linux ;)
I've tried it with.  Seeing as though this part of the spec is most
foreseeably useful for cdroms, I'll point you to something I did a quick
Google for:

http://aplawrence.com/Bofcusm/1324.html

So far this is sapping the spec of its usefulness.  I did a search in
the archives, and someone else seemed to mention that directories are
also valid candidates for autoopen.  I agree.

I understand that this is a matter of security; however, I would suggest
that the execute bit be explicitly ignored.  Hopefully this wouldn't
result in kludgey vfs work-arounds.  On that note, I'll again quote the
spec:

When an Autoopen file has been detected and the user has confirmed that
the file indicated in the Autoopen file should be opened then the file
indicated in the Autoopen file MUST be opened in the application
normally preferred by the user for files of its kind UNLESS the user
instructed otherwise.

This implies that the user "MUST" be prompted (shouldn't this be
explicit to avoid mis-interpretations?) and be given the same
responsibility one requires when opening any media, visiting any
website, or otherwise using one's computer.  This seems simple enough to
me.  Removing the execute bit and prompting the user will give the same
level of security that would otherwise be given without the execute bit
in the first place.

Hopefully I haven't wasted your time with something that has been addressed.