W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: Chair review of the issue-189 change proposals

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 27 Mar 2012 18:42:18 +0200
Message-ID: <4F71EDEA.10901@gmx.de>
To: Sam Ruby <rubys@intertwingly.net>
CC: "public-html@w3.org" <public-html@w3.org>, "Edward O'Connor (ted@oconnor.cx)" <ted@oconnor.cx>
On 2012-03-27 13:09, Sam Ruby wrote:
> 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.

"web+ scheme prefix" is in the IANA registration section, so yes, it 
*does* take that position.

> "thus the spec is in violation of the URI registration procedure"

See above.

> 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.

The details in my proposal *re* to drop the convention.

> "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.

The SecurityError would be thrown for any scheme not in the white list 
of schemes. So yes, it's an extension point lost for now. I think that 
statement is correct as it stands.

> 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
>
>

Best regards, Julian
Received on Tuesday, 27 March 2012 16:43:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:31 UTC