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

Re: Working Group Decision on ISSUE-189 uri-prefix

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 06 Aug 2012 12:51:41 +0200
Message-ID: <501FA1BD.2020202@gmx.de>
To: public-html@w3.org
On 05.08.2012 22:03, Maciej Stachowiak wrote:
> The decision follows.  The chairs made an effort to explicitly address
> all arguments presented in the Change Proposals on this topic as there were no
> additional responses in the poll itself.
>
> *** Question before the Working Group ***
>
> There is a disagreement on whether to apply special meaning to the web+
> URI scheme prefix, tracked as ISSUE 189.
> We have two distinct proposals for this question, and a straw poll for
> objections.
>
> http://www.w3.org/html/wg/tracker/issues/189
> "Assign no special meaning to the web+ prefix"
>      http://lists.w3.org/Archives/Public/public-html/2012Feb/0272.html
> "Disambiguate the web+ prefix"
>      http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-189
> https://www.w3.org/2002/09/wbs/40318/issue-189-objection-poll/results
>
> == Uncontested parts of the proposals:
>
> The following points were made and not disputed, and in some cases
> explicitly stipulated by both proposals:
>
> - The spec should not present material regarding a URI scheme
>    prefixing convention as if it were an IANA registration, or in a
>    manner that is easily confusable for an IANA registration.
> - "This CP [Disambiguate the web+ prefix] fixes the problem of the
>    specification trying to register a URI scheme prefix."
> - There is a use case for the "web+" URI scheme prefix: enabling
>    websites to expose services with custom URI schemes to
>    registerProtocolHandler.
>
> They are assumed valid in the analysis below.
>
>
> == Use cases for the Web+ prefix:
>
> The Change Proposal to "Disambiguate the web+ prefix" argues that there
> is a valid use case for the "web+" URI scheme: extending the set of URI
> schemes that can be registered via registerProtocolHandler in a safe and
> extensible way. A specific example is provided: a "web+macro" scheme for
> services that allow the creation of image macros. No specific evidence
> was provided, but the example seems plausible.
>
> The validity of this use case was not disputed. Nor did the competing
> proposal provide another way to satisfy the same use case. It's also
> been mentioned (in notes linked from the survey) that this feature has
> been multiply implemented, providing some tentative evidence that some
> browser implementors believe it to have value.
>
> Thus, this is a moderately strong objection to the Change Proposal to
> "Assign no special meaning to the web+ prefix". To determine whether
> this holds up, we need to examine whether the feature causes harm that
> outweighs the value of the use case.
>
>
> == Invalid IANA registration:
>
> The authors of both proposals seem to agree that the text in the
> current draft could readily be interpreted as an IANA
> registration. Both also seem to agree that either Change Proposal
> would remedy this. Thus, this was not taken as an objection to either
> proposal.
>
>
> == Coordination with IETF and IANA:
>
> The Change Proposal to "Assign no special meaning to the web+ prefix",
> as well as survey commenters, mentioned that coordination with IANA and
> IETF is desirable. Survey comments also indicated that some initial
> coordination steps have taken place, including email contact, and
> later discussion during a W3C/IETF coordination call. The information
> provided in Change Proposals and survey comments did not include
> requests for any specific changes from the IETF or IANA. While input
> from these organizations would have significant weight, they have to
> date not asked for anything specific.
>
> Some coordination has taken place. No concrete request for change has
> resulted so far. While additional feedback could be forthcoming in the
> future, the possibility of future feedback does not seem like enough
> by itself to remove a feature with a valid use case. No specific
> reason was given why removal pending more discussion would be an
> appropriate remedy. Thus, this was taken to be a weak objection.
>
> One commenter suggested that for HTML5 to assign a special meaning to
> a URI prefix, it should be simply registered with IANA. However, the
> original impetus for this issue was that there is no such registration
> procedure, and therefore, HTML5 should not give the appearance of
> entering such a registration. Thus, this was also taken to be a weak
> objection.
>
>
> == 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.
>
>
> *** Decision of the Working Group ***
>
> Therefore, the HTML Working Group hereby adopts the "Disambiguate the
> web+ prefix" proposal:
>
>      http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-189
>
> Of the Change Proposals before us, this one has drawn the weaker
> objections.
> ...

I'm confused.

<https://www.w3.org/2002/09/wbs/40318/issue-189-objection-poll/results> 
indicates that the change proposal got two objections, while the other 
one got none.

Could you please explain where the other objections came from?

Best regards, Julian
Received on Monday, 6 August 2012 10:55:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:26 UTC