- From: Sam Ruby <rubys@intertwingly.net>
- Date: Tue, 27 Mar 2012 07:09:10 -0400
- To: "public-html@w3.org" <public-html@w3.org>
- CC: Julian Reschke <julian.reschke@gmx.de>, "Edward O'Connor (ted@oconnor.cx)" <ted@oconnor.cx>
http://dev.w3.org/html5/status/issue-status.html#ISSUE-189
"Prefix convention needs to be coordinated with IETF"
----
Observations/facts that do not appear to be in dispute:
* Despite one Change Proposal making the claim that "coordination
is needed" in its summary section, none of the details of either
Change Proposal identifies any additional coordination activities
to be pursued with the IETF.
* The IETF in general, and RFC 4395 in specific, does not provide a
means to register a pattern of mime types.
* The current HTML5 editor's draft associates conformance criteria
and behavior with an infinite number of yet-to-be-registered mime
types.
* The current HTML5 editor's draft presents the convention in a way
that creates confusion.
=======================================================================
Review of the following proposal:
http://lists.w3.org/Archives/Public/public-html/2012Feb/0272.html
"the spec takes the position that registration of scheme name prefixes
is possible"
Drop this. The current spec text presumes that describing a
convention is possible. It does not presume that IETF registration
of such a convention is possible. In fact, everyone seems to agree
that IETF does not provide such a mechanism.
"thus the spec is in violation of the URI registration procedure"
Please support this conclusion or drop this assertion.
"Until the problem described above is resolved"
Drop this. We do not accept conditions in proposals. Feel free to
propose a registration mechanism. Feel free to propose that this
function be deferred to a future release of HTML. But make a
specific proposal and be prepared to support that proposal with
technical arguments.
"Coordination can happen with the standards body that controls URI
scheme names."
Either propose a specific set of actions and desired outcome, or
drop this statement.
"The protocol handler feature looses an extension point for now."
This is more than simply an extension point involved. There is
specific testable behavior involved, e.g., "throw a SecurityError
exception". Either explain how this behavior gets specified and
standardized or explain why it is not important to standardize this
behavior at this time.
=====================================================================
Review of the following proposal:
http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-189
While there may be additional feedback should Julian's proposal be
updated, this feedback is focused on what is being proposed,
specifically: "Alter the appearance".
As the appearance of the section of the specification under
consideration is fundamental to what is being proposed in this specific
proposal, and as the editor seems to believe that what currently is in
the spec is sufficiently visually distinct from IANA registrations to
prevent confusion, please obtain and incorporate any feedback you feel
is necessary from the editor prior to this proposal being included in a
call for consensus or survey.
- Sam Ruby
Received on Tuesday, 27 March 2012 11:09:40 UTC