On Fri, 2012-08-24 at 23:28 +0200, Ondřej Surý wrote: > Also I don't think you have a definitive say in what associations are > needed in mime-support package. It's up to individual "users" of > mime-support package (read individual packages) to define what they > need for correct functionality. I think of mime-support like kind of > "support" package. I personally, think, we can add unofficial definitions (*/x-*)... if, and only if, they are needed / used by people, i.e. when there's a strong demand (what ever this is ;) ). Otherwise, we can start to add definitions for basically all file types out there. And adding x-* types (when there is no real strong need for them) also has its disadvantage,... people will get used to it and depend on an unofficial definition. I haven't checked the details of the requesting bug, but at least with respect to webserving I'd say a */x-php type makes perhaps little sense, as php is in most cases interpreted (where we have now a better solution :) ). > Also please write technical reasons why text/x-php (or > application/x-php whatever) is wrong. Unless you can come up with > technical reasons (f.e. it breaks something) please leave it in the > place, as it fixes critical bug (a regression) in processing PHP files > inside apache (and maybe also in other places). > It's explained in #670945: Ok I looked into it... now: Maybe well need to go that way now for wheezy... but IMHO... it's generally a bad idea to use negotiation with any interpreted files. Actually I'd even prefer to disable negotiation altogether (per default)... is has many (intended) side effects,... and should therefore be intentionally enabled. > > Please do not use: > > text/x-php > > but replace it with: > > application/x-php > > > > The use of text/ for interpreted languages (scripts) is discouraged > > already by IETF and things like javascript/ecmascript are already > > migrated to application/*, the legacy text/* definitions being > > deprecated. > > Chris, this is surely not critical severity. I have cloned your bug > report, assigned it a right severity and retitled it to "mime-support: > use of text/ for interpreted languages is discouraged" since we have > several interpreted languages in our mime.types Ooops... forgive me,... I forgot that the original bug hat that priority. Thanks for cloning out... :) Anyway, we should try to get it with application/ in wheezy,.. otherwise people will start using it... > text/x-perl > text/x-python > text/x-tcl > text/x-sh > text/x-java > text/x-haskell > [...] You're right,... eventually they should all go,.. but apparently this has the potential for breaking many things... > Fedora has already moved perl to application/x-perl, so basically I > agree with you, but I would suggest we keep all the languages in sync > and move them post release. I would be quite a huge change to mingle > with existing MIME-Types in the freeze. Definitely... > We might start by syncing MIME-Types with IANA since we are missing > too many new MIME-Type definitions, but again I think it's already too > late in the release cycle to think about that, but again I do not > speak for release team. Well I (but of course neither I speak for them),... would leave the ones with text/* that were already in. Using text/ for interpreted scripts is not strictly forbidden (e.g. text/ecmascript is still defined),... it's just deprecated. Maybe the mime-support maintainer(s) can set these as goals for jessie :) Syncing with IANA and cleaning up unofficial definitions. :) Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature