On Tue, 2012-08-28 at 16:05 +0200, Vincent Lefevre wrote: > It doesn't break anything. Well one should usually not add any "personal" interpretations to standards,... because eventually this will cause troubles.
> If the goal is to read the file as text, > then text/plain is fine. Ah... I guess I over-read that :D I thought you were talking about e.g. "text/x-php"... text/plain is of course fine, as well as (for example) application/octet-stream. > 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. Yep you're right,... I over-read that :D... but this thread goes about text/x-php, which I still think would be wrong,... not about marking them as text/plain. > text/x-javascript could be used to, in order to provide information > about the language, even though it is not standard (hence the "x-"). 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. And if e.g. an email client is smart enough to know that text/x-javascript is not to be executed but that it should use JavaScript highlighting, then it can easily be smart enough, too, to know that it shouldn't execute application/javascript per default, but rather display it. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
