On Tue, 2012-08-28 at 15:41 +0100, Ian Jackson wrote: > > > You misread what I've said. text/javascript and text/ecmascript > > > (which were used for execution -- this is what this RFC is about) > > > are obsolete, but not text/plain. > I think this is probably a mistake by the IETF. Well, I doubt, but anyway... I guess than one would need to discuss with them to correct it. > Do you think then that the source code language (eg for syntax > highlighting or whatever) should never be represented in a mime type ? I think it already is when you use e.g. application/javascript. And I think, that MIME types are intended to hint the client of what kind content is, but not what to do with it. The clients can then decide what to do, depending on fit's best for them, or ask the user, or do the action the user has previously configured. In the specific example of interpretable scripts, it's of course reasonable to not set the default action to execute it (for security reason). But that's not something the server should tell (by the MIME-type),... it cannot know what the client/user really wants... and it would be insecure to trust any remote server to make the right choice. > > Yeah,.. could... but... I think adding a x- type for widespread use > > should always be the last solution, sooner or later these may cause > > troubles. > I don't agree with this. Well... x- types were never intended to be used in production. - They always bear the risk, that they're ambiguous, Microsoft defined it to be xyz, Adobe defined it to be zxy. - Once you've defined (and used) them widely, you cannot easily get rid of them. The application/x-httpd-* case is an example, as well as several types for which previously an x-type existed but now a real definition was made. Both continue to be used and for both code has to be maintained. - People often "defined" x-types without really knowing what they do. There are types for bzip2 or gzip floating around (luckily not in Debian's mime-support) which are however not types, but encodings. - And x-type gives you no guarantee at all, that anyone else agrees with it or even supports it. Of course the same is true with official types, but there one at least has kind of a "strong" argument, that 3rd parties should support them, which you don't have IMHO with x-types. > In the latter case we need to teach _all_ user agents to display > application/javascript rather than do something else with it. Yeah,... but what else? I mean user agents that unconditionally try to execute/interpret application/* content are seriously flawed... > In the > former case we only need to teach anything to those user agents for > which text/we think a prettier display than that available for > text/plain is desirable. Well at least for the cases I know (but these are surely not all),... it works already fine as it is... either they understand that e.g. application/javascript is to be displayed as text in editor (e.g. with syntax highlighting)... or in case of text/plain,.. they try anyway to automagically determine the correct highlighting. Even if we'd need to fix any client... we're in the open source world, arent't we? In most cases it's just a one liner to tell an user agent that it should connect type application/foo with e.g. editor bar. Of course you can argue that we can't to this for proprietary crap,... but why should we mess up our systems to make their crap work out of the box? I just suffered (few minutes ago) again from an issue in Outlook, that it cannot display S/MIME signed (not encrypted) mails if it doesn't know the key... it does not just warn, it really cannot display it. Now should I change my working and correct setup just to please any big company like Dell which uses Outlook? And if a server admin really needs to do this,... he can always manually add such types,... but IMHO there's no need to "poison" all users with them ;) Anyway... I guess the whole discussion went highly off topic, didn't it? The question is what should be done for text/x-php and text/x-php-source and from my side I've already said mostly everything what I'd do and that I think using mod_negotiation for "tidy" URLs is an abuse an shouldn't be supported :) Cheers Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature