"who should be in charge of defining what text/html and application/xhtml+xml are" ... "And we have two groups that are in charge of that"
IANA is in charge of the MIME type registry, and IANA policy is to follow IETF recommendations, generally expressed in the form of RFCs approved by the IESG which include sections labeled "IANA considerations". By determining IETF consensus, IESG approved RFC 2854, http://www.ietf.org/rfc/rfc2854.txt , written by Dan Connolly and myself, which delegated change control for "text/html" to "the W3C". Decisions by the W3C are controlled by the W3C process, which member companies, through their membership agreement, have signed and agreed to. Similarly, "application/xhtml+xml" is registered by RFC 3236, http://www.ietf.org/rfc/rfc3236.txt, written by Mark Baker and Peter Stark, which also delegates change control for "application/xhtml+xml" to "the W3C". So, "who is in charge of defining what text/html and application/xhtml+xml", the answer is * The IETF approved the RFCs which registered these types and delegated further decisions to "the W3C". One could ask the IETF to give the authority to some other organization, if necessary, but currently it is "the W3C". * The W3C makes decisions under the published W3C process, where publication of W3C recommendations are made through approval of the Director, who gets the advice of the Advisory Committee and then decides. Director decisions can be appealed to the advisory committee, if there is some disagreement with the directors assessment. Traditionally, the W3C mainly left some specifications about "the web" to IETF and IANA, including the meaning of MIME types, the definition of the HTTP protocol, the definition of the URI protocol element, etc. There have been some cases where some W3C working groups either attempted to override those definitions or modify them for the purposes of particular W3C specifications, e.g., redefining use of HTTP to include "MIME type sniffing", or redefining "URI" to mean "extended IRI" in the context of some W3C specifications. I think this trend is reversing, fortunately. Overlapping normative specifications are less significant a problem if the specifications are both under the control of the same working group; normative overlap between different W3C committees (WebAPPS vs. HTML, HTML vs XHTML) is a problem. But normative overlap between separate organizations (W3C vs. IETF or OASIS) is a more significant problem, and I hope these areas can be corrected. (Getting rid of normative overlap between W3C publications and obsolete IETF RFCs was the motivation for RFC 2854, for example.) Larry -- http://larry.masinter.net
