[whatwg] Registering protocol handlers

On Thu, 13 Apr 2006, Christian Biesinger wrote:
> 
> so, the latest WhatWG spec has a way to register protocol handlers: 
> http://whatwg.org/specs/web-apps/current-work/#browser
> 
> Its specification seems to have some issues:
> - The mimeType argument description says "If mimeType values passed to this
> method include characters such as commas or whitespace"
>
> It seems to me that using "such as" in a normative part of the 
> specification is a rather bad idea. This also doesn't define what to do 
> with syntactically malformed types (throw an exception or do nothing?).

That's not a normative conformance statement, it's a statement of fact. 
The normative conformance statement that results in this statement of fact 
being true is the sentence immediately following it: "User agents must 
compare the given values only to the MIME type/subtype parts of content 
types, not to the complete type including parameters."

I've clarified this (hopefully) by reversing the order of the sentences.


> (Are schemes ever syntactically invalid as far as this method is 
> concerned, and should an exception be thrown if they are?)
> 
> - What should happen with a syntactically malformed URI? Exception or 
> silently do nothing?

Per the spec, the methods do not check the syntactic validity of their 
arguments except for two things: The URI not having a %s, and the scheme 
or content types being "privileged" (http:, text/html, etc).


> - The character set that should be used before escaping the URI is not 
> defined. I assume it's UTF-8 (for all parts of the URI, including the 
> query)?
>
> - Which characters should be escaped? The example that's later given 
> seems to imply "everything that's not an ASCII alphanumeric character". 
> Is that the right interpretation?

I've fixed these issues. Thanks. Let me know if there is still a problem.


> - The section "4.10.2.1. Security and privacy concerns [...]" has an
> informative-sounding heading but does in fact seem to have normative
> statements like "User agents must never send username or password information
> in the URIs that are escaped and included sent to the handler sites."

Non-normative sections are explicitly marked. However, if you can think of 
a better section title I'm open to suggestions.


> - The spec doesn't say what should happen if multiple pages try to 
> register a handler, but maybe that's intentional (should it say that 
> this is outside the scope of the spec?)
> 
> - It also doesn't define what exactly the registered handlers should be 
> applied to (just link clicks/loads initiated from URL bar and similar), 
> or also embedded content, but this seems to be intentional?
> 
> But maybe all that doesn't matter so much, given:
> "User agents may do whatever they like when the methods are called."
> "This section does not define how the pages registered by these methods are
> used."
> ???
> 
> Is this feature a serious part of the spec? Why bother specifying the 
> above when UAs can ignore it or parts of it anyway? With this amount of 
> undefined behaviour, there doesn't seem to be any hope for 
> interoperability.

The answer to all these questions is basically the same:

What would you want the spec to say?

I can't require a particular UI. It's the same as the part of the spec 
that defines what happens when you click a link -- to a large extent, it's 
up to the UA. It could save the document, render it in a new tab, in a new 
window, e-mail the link to someone, copy the link to the clipboard, or 
whatever. It's not up to the spec to define that. The spec just defines 
the API; how that is represented in the UA is up to the UA vendor.

However, if you have any specific text you would like to see in the spec 
to cover these questions, let me know.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 13 April 2006 16:49:06 UTC