Working Group Decision on ISSUE-189 uri-prefix

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.


== Next Steps ==

Since the prevailing Change Proposal does not call for a spec change,
no further action is required. ISSUE 189 will now be closed.


== Appealing this Decision ==

If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition
request.


== Revisiting this Issue ==

This issue can be reopened if new information come up. Examples of
possible relevant new information include:

* Suggestions of alternate approaches to registerProtocolHandler
  extensibility that have traction with implementors but avoid the
  claimed problems of the "web+" prefix approach.

* Evidence that registerProtocolHandler extensibility is not a valid
  use case.

* Specific requests from IANA or IETF to make changes to the spec or
  solve the problem in a different way.

* Specific evidence of concrete problems caused by the "web+" prefix
  approach; for example, supporting evidence for the claimed
  scalability problems.

Received on Sunday, 5 August 2012 20:03:58 UTC