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

Chair review of the issue-189 change proposals

From: Sam Ruby <rubys@intertwingly.net>
Date: Tue, 27 Mar 2012 07:09:10 -0400
Message-ID: <4F719FD6.80607@intertwingly.net>
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>

"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
   *  The current HTML5 editor's draft presents the convention in a way
      that creates confusion.


Review of the following proposal:


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


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

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:50 UTC