[Bug 6684] Disregard of RFC 4329 and IANA MIME Media Types

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6684





--- Comment #21 from Ian 'Hixie' Hickson <ian@hixie.ch>  2009-04-02 00:51:40 ---
Could you please either give at least a single benefit to authors using these
new types or admit that there is no such benefit?


> Maybe obscure for you. Less obscure for some browser and HTTP server vendors
> and for some web authors, who already use these new mimetypes in practise.

It's not obscure to me, I was even consulted in its creation. It _is_ obscure
to most Web authors; just go into any Web authoring forum and ask them what the
MIME type for JavaScript is.


> Concerning XML and XHTML -- why and for what reason do the application/xml and
> application/*+xml mimetypes exist, when the text/* domain may also be
> sufficient?

Because the people who wrote the XML MIME type RFCs thought it was easier to
introduce a raft of new types than to fix the underlying MIME RFCs with respect
to default encodings. We are still suffering the problems that were caused by
this fiasco.

However, even this doesn't apply here, since browsers uniformly ignore the MIME
type, and only look at the charset parameter, ignoring the defaults that were
being worked around by the XML MIME type RFCs.


> > If it would help, I don't mind adding the new types to section 4.3.1.1
> > Scripting languages. I added the following to section 2.2.1 Dependencies: "The
> > MIME type used to refer to ECMAScript in this specification is text/javascript.
> > This is a willful violation of RFC 4329. [RFC4329]" 
> 
> Please add at least, WHY you want willful violate RFC 4329.

Done.


> And among that: the
> user should use "text/javascript", if he uses ECMAScript? You have to explain
> that: a JavaScript referring Mimetype for a language that isn't JavaScript but
> ECMAScript?
> When using/referring to ECMAScript, why not at least "text/ecmascript"?

You're right, using the term ECMAScript is a bit confusing. I've gone through
and changed everything to consistently refer to the language as JavaScript
(previously it was a bit mixed).


> Ian, why not going the same way as the W3C has gone with text/html and
> application/xhtml+xml for XHTML? Why not use the well known key words "MUST",
> "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> "OPTIONAL" -- and wire text/javascript and text/ecmascript with the keywords
> "MAY" or better "SHOULD NOT" to comply with RFC 4329 and wire
> application/javascript and application/ecmascript with the keywords "SHOULD" or
> "RECOMMENDED" to comply with RFC 4329?

How does using application/ecmascript instead of text/javascript in any way
benefit authors? This is not a rhetorical question. It is the crux of the
matter. Please can you give a single such benefit?

I've added the various RFC4329 types to the list of types that are possible, if
that matters.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 2 April 2009 00:51:50 UTC