This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
RFC 2854: Author/Change controller: The HTML specification is a work product of the World Wide Web Consortium's HTML Working Group. The W3C has change control over the HTML specification. HTML 5: W3C and WHATWG Potential issues: 1) the W3C needs to approve that change control is changed 2) in case of a future conflict between W3C and WHATWG, who will actually *have* change control? I would assume IANA needs to know that.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: For #1, I assume that this will be checked when the change is submitted with LC. For #2, I guess in practice it would be whoever got there first. :-) In practice the whole "change control" field doesn't much matter — if IANA doesn't recognise the authority of whoever is actually writing the specs that are being used, then that will just make the IANA irrelevant and another registry will effectively have to take over. If the IANA _does_ recognise the authority of whoever is writing the specs that are being used, then they would have to ignore the change control field if it referenced a group that no longer was writing those specs. Personally I would much rather we just made the change control blank, and let the community handle it via mutual recognition of authority — for example, if the W3C and the WHATWG go crazy and start making specs that the implementors are ignoring, then another group should be able to come along and write a new spec and take over text/html over the objections of the W3C and the WHATWG, so long as the community as a whole supports (via implementations and deployment) that group rather than the W3C and the WHATWG. (Marking LATER since #1 is an LC-transition issue.)
I don't think the reply is helpful. We are updating an IANA registration, so we are subject to their rules. Re-opening, as this needs to be addressed at some point of time (the earlier, the better). Setting it to resolved when it's not resolved doesn't make sense.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: If you don't want me to address it later, then I guess I have to reject it, since I can't do it now. It is inappropriate to do #1 now and #2 is irrelevant, as discussed in comment 1.
Julian, do you have a suggested title and description for the issue? Any chance you could just raise it yourself? (Side note: it seems like the issues here are: A) For IANA: What are IANA requirements on updating the change controller? Do they need approval for a change? Do they allow joint change control? B) For W3C: Is W3C willing to agree to joint change control, if IANA allows such a thing? When in the W3C process does the IANA registration request need to get submitted? These are factual questions where we need to get an answer from the relevant organizations. It seems like the answers would immediately clarify what action, if any, is needed. Getting those answers might be more productive than creating a tracker issue. I can work on (B), but I do not know the proper way to contact IANA about these matters.)
(In reply to comment #4) > A) For IANA: What are IANA requirements on updating the change controller? Do > they need approval for a change? Do they allow joint change control? The only way to find out for sure is to either officially ask IANA (maybe through the W3C/IETF liaison call), or by trying.
The current media type is defined in http://www.faqs.org/rfcs/rfc2854.html IESG discussed the ownership of the text/html and indicated: - current change controller is W3C - there can be only one owner for the media type, so the current proposal "WHATWG and W3C" isn't acceptable to them See item 9 in http://lists.w3.org/Archives/Public/public-ietf-w3c/2010Mar/0002.html (I don't know if the minutes of the IESG itself are public) At the present, I don't believe that W3C would agree to have a joint change control but W3C do need to make sure to come up with a consistent story regarding the use of text/html. For example, HTML5 doesn't say anything about XHTML 1.1, while XHTML 1.1 does mention the text/html media type. Obviously something needs to be fixed. Imho, the text/html should only be defined in the HTML5 specification. I suggest following http://www.w3.org/2002/06/registering-mediatype.html#Planned
Julian, would you be ok with reopening this bug instead of escalating it, given the information Philippe provided? I think we now know: - A request for joint change controllers would be rejected by IANA. We have a clear statement on this from the IETF. Thus, the current registration text needs to be fixed, or our MIME type registration will be rejected. - IANA will not change the change controller without approval of the previous change controller. W3C does not agree to transfer control of text/html, either entirely or in part. We have a clear statement on this from the W3C.
Sure. TrackerRequest removed, bug reopened.
(In reply to comment #6) > but W3C do need to make sure to come up with a consistent story > regarding the use of text/html. For example, HTML5 doesn't say anything about > XHTML 1.1, while XHTML 1.1 does mention the text/html media type. Obviously > something needs to be fixed. Imho, the text/html should only be defined in the > HTML5 specification. Perhaps it is only a choice of words but ... XHTML 1.1 does not mention 'text/html'. [1] And also: Part of the "consistent story" has to be I suppose RDFa, whose DTD is based on XHTML1.1 and which also is "touted" by the W3.org as the big thing right now, and docs with the RDFa doctype are, realistically, often served as text/html. The XHTML1.1. spec itself purports to be a XHTML 1.1. document - but is served as 'text/html' Since for ever? Right now, the W3 Validator considers lang="*" as valid in XHTML 1.1. documents [3] (I don't know for how long.) and the XHTML2 WG plans to make lang="*" valid. The current, material differences between XHTML1.1. and XHTML1.0 according to XHTML1.1 itself, are: [2] 1) "the lang attribute has been removed in favor of the xml:lang attribute" 2) "On the a and map elements, the name attribute has been removed in favor of the id" 3) "The "ruby" collection of elements has been added (as defined in [RUBY])" Of which only RUBY is a real difference and the only place where XHTML1.1. possibly is stepping on the feet of HTML5 (depending on the outcome in HTML5 itself! ) To make lang="*" valid in XHTML 1.1. documents seems more like acknowleding the spirit of HTML5, than the opposite. But perhaps the problem could be explained better, somewhere? Except with regard to RUBY, I wonder what the problem is. E.g. I don't think that XHTML1.1. plus MathML should be placed in the same category as XHTML1.1. [1] http://www.w3.org/TR/xhtml11/xhtml11 [2] http://www.w3.org/TR/xhtml11/xhtml11#a_changes [3] http://lists.w3.org/Archives/Public/www-validator/2010Mar/0039
(In reply to comment #9) > The XHTML1.1. spec itself purports to be a XHTML 1.1. document - but is > served as 'text/html' > Since for ever? It appears it has been that way since before XHTML 1.1 first edition transitioned to REC, which means XHTML 1.1 PR would have been in violation of Pubrules as Pubrules exist today. (I didn't check if Pubrules were different on this point at the time of XHTML 1.1 1st ed. PR publication.) It seems to me that there's been quite a bit of selective attention paid to the W3C rules in the sense that the (current) HTML WG gets much more Process scrutiny than the XHTML2 WG. It seems weird that the media type change controller issue gets this much scrutiny in the context of the HTML WG while the XHTML2 WG publishes rules about text/html in a Note that isn't subject to the reviews provided by the W3C Process.
(In reply to comment #0) > RFC 2854: > > Author/Change controller: > The HTML specification is a work product of the World Wide Web > Consortium's HTML Working Group. The W3C has change control over > the HTML specification. > > HTML 5: > > W3C and WHATWG > Thinking about this a bit: It seems that one possible way to update the RFC2854 would be to state the the HTML specification is a joint work product of W3C and WHATWG, and that the W3C has change control over the relevant MIME registrations. I believe both of those statements would be true, since it's the W3C process (and not any WHATWG process) that triggers submission of a revised MIME type registration.
(In reply to comment #11) > ... > It seems that one possible way to update the RFC2854 would be to state the the > HTML specification is a joint work product of W3C and WHATWG, and that the W3C > has change control over the relevant MIME registrations. I believe both of > those statements would be true, since it's the W3C process (and not any WHATWG > process) that triggers submission of a revised MIME type registration. > ... Sounds good to me. If we move the registration from RFC 2854 into an non-IETF document we *still* will have to decide *which* document to point to (unless we want to guarantee that both copies say the same thing, which, right now, doesn't seem to be the case).
(In reply to comment #12) > (In reply to comment #11) > > ... > > It seems that one possible way to update the RFC2854 would be to state the the > > HTML specification is a joint work product of W3C and WHATWG, and that the W3C > > has change control over the relevant MIME registrations. I believe both of > > those statements would be true, since it's the W3C process (and not any WHATWG > > process) that triggers submission of a revised MIME type registration. > > ... > > Sounds good to me. > > If we move the registration from RFC 2854 into an non-IETF document we *still* > will have to decide *which* document to point to (unless we want to guarantee > that both copies say the same thing, which, right now, doesn't seem to be the > case). Is that something that has to go in the spec? I assume when W3C submits an updated MIME registration for text/html and application/xhtml+xml, it will provide a pointer to the W3C copy of the spec. But I don't think the spec needs a self-link for that to happen.
(In reply to comment #13) > Is that something that has to go in the spec? I assume when W3C submits an > updated MIME registration for text/html and application/xhtml+xml, it will > provide a pointer to the W3C copy of the spec. But I don't think the spec needs > a self-link for that to happen. That is true. So if we can all agree that in fact is the plan, I'm happy (with the clarification proposed in comment 11).
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: http://html5.org/tools/web-apps-tracker?from=5013&to=5014 Rationale: Since the W3C doesn't want to relinquish control and since the IETF doesn't recognise joint efforts, I've put the change controller as W3C for the already-registered types, and WHATWG for the new ones. As I wrote in comment 1: In practice the whole "change control" field doesn't much matter — if IANA doesn't recognise the authority of whoever is actually writing the specs that are being used, then that will just make the IANA irrelevant and another registry will effectively have to take over. If the IANA _does_ recognise the authority of whoever is writing the specs that are being used, then they would have to ignore the change control field if it referenced a group that no longer was writing those specs.
This is progress, but as far as I understand not sufficient: For text/html-sandboxed, I don't see how the change controller can be different from the one for text/html.
(In reply to comment #16) > This is progress, but as far as I understand not sufficient: > > For text/html-sandboxed, I don't see how the change controller can be different > from the one for text/html. Perhaps that should be a separate bug, for clarity. text/html-sandboxed is not already registered with the W3C as a change controller, so none of the content in comment 1 or comment 6 applies. (I'm not saying I disagree with your suggestion, but it seems different from this bug, which was all about changing the previous Change Controller for already registered types).
reresolving per comment 17.