- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 13 Aug 2012 13:32:18 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- CC: "public-html@w3.org WG" <public-html@w3.org>
On 2012-08-13 11:36, Maciej Stachowiak wrote: > > On Aug 13, 2012, at 2:02 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > >> On 2012-08-05 22:03, Maciej Stachowiak wrote: >>> ... >>> == Architectural issues: >>> >>> Survey commenters objected to the architectural design of the web+ >>> prefix approach to extending valid URI schemes for >>> registerProtocolHandler. One wrote, of the "Disambiguate the web+ >>> prefix" proposal: >>> >>> It does not address the problem of overloading the naming of URI >>> schemes with semantics. Doing this in general is problematic as it >>> doesn't scale; once a prefix is defined this extension point is >>> essentially taken. >>> >>> The only specific problem identified was "doesn't scale". However, >>> it was not explained what scaling means in this regard, nor was evidence >>> provided that the feature doesn't scale. Other aspects of Internet >>> protocols and the Web platform are based on name registries of various >>> sorts, so some evidence would need to be provided for why it would be >>> a problem in this case. >>> ... >> >> I thought that was obvious. It doesn't "scale" in that each URI scheme name has a *single* prefix, thus what HTML5 tries to do here can not be done again by another spec. > > If you want to request a reopen of the decision, then feel free to put together a Change Proposal presenting new information. I am not sure the statement above would suffice, because for example it does not explain how the web+ convention would be more problematic than the +xml convention of RFC3023. (I realize MIME types and URI schemes are not the same thing, but suffix, just like prefix, is a unique lexical position within the identifier.) A more complete explanation of the problem embedded in a Change Proposal may be sufficient. It's an extension point that can only be used once, and thus should be controlled by the body that controls the scheme names. That being said, see discussion thread starting at <http://lists.w3.org/Archives/Public/public-ietf-w3c/2012Aug/0000.html>; I expect that once we are done with that discussion we'll want to re-open the issue (that's exactly why I said previously that it's sub-optimal timing to force closing the issue right now). Best regards, Julian
Received on Monday, 13 August 2012 11:32:47 UTC