- From: James P. Salsman <bovik@best.com>
- Date: Thu, 2 Mar 2000 00:02:32 -0800 (PST)
- To: walter@natural-innovations.com
- Cc: www-html@w3.org
Walter, Thanks for your message: >... How about ACCEPT="audio/aifc; device=microphone" ? Those parameters following the semicolon modify the type, so for example, you might have "audio/l8;rate=8000;channels=1" for low-quality 8-bit monophonic audio, of "audio/l16;rate=48000;channels=2" for DAT-quality stereo. If you were to use that form, then you might have to regester a "device" parameter for each MIME type, and code it in for each type alternative that you ACCEPT. But I do agree with everyone who says that RFC-1867-style file uploads could be device uploads using the ACCEPT attribute, if you're willing to give up a default device selection. And indeed this wouldn't involve changing anything in the specs. But if it were such a good idea, wouldn't it have been done? The problem is, there are no browsers that do anything like that -- the big-two wintel browsers interpret ACCEPT as a filename pattern! The only way to obtain device upload does not even involve the INPUT tag (on Windows' MSIE, the OBJECT tag is used with an insecure "ActiveX" binary; on Netscape Navigator under Windows, the EMBED tag is used with a similarly insecure arrangement where the user must "Grant All" system privleges to the EMBEDed binary code.) This complex state of affairs need not be so. If the W3C would just take a stand, and tell the browser vendors that in order to be compliant with the W3C Recommendations, if device upload is implemented then it should be available in a certain way, then they would probably conform to stay compliant. But the W3C has never taken a stand on device upload, so the fact is that only wintel users get it, in different, incompatible, and dangerously insecure ways. I have been asking the W3C to take such a stand since 1997. Cheers, James
Received on Thursday, 2 March 2000 03:02:48 UTC