- From: Peter Saint-Andre <stpeter@stpeter.im>
- Date: Wed, 01 Aug 2012 12:37:00 -0600
- To: Philippe Le Hegaret <plh@w3.org>
- CC: Barry Leiba <barryleiba@computer.org>, Mark Nottingham <mnot@mnot.net>, public-ietf-w3c@w3.org, Edward O'Connor <eoconnor@apple.com>
On 8/1/12 11:33 AM, Philippe Le Hegaret wrote: > Following the morning discussion, here are the links to the web+ > definition: > > http://www.w3.org/TR/html5/system-state-and-capabilities.html#custom-handlers > look for the item on scheme (registerProtocolHandler() only) > > http://www.w3.org/TR/html5/iana.html#web-scheme-prefix > Note that the Working Group is about to decide that this section needs > rewrite because it must not look like an IANA registration. > > I also suggest to look at the rational section of a change proposal > related to this: > http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-189#Rationale Philippe, thank you for posting about this issue. IMHO, Ted's adjustment is an improvement, because at least that makes it clear that no IANA registration is being made here. That said, I have one question and two concerns about the proposed "web+" prefix for URI schemes. Question: Is there any expectation that designated experts or the IANA will need to handle schemes with the "web+" prefix differently from URI schemes without the "web+" prefix? For example, will reviewers need to verify that such schemes are not "used for features intended to be core platform features" or cannot be used to "store confidential information in their URLs, such as usernames, passwords, personal information, or confidential project names"? (Quotes from the proposed HTML spec as of this date, Section 6.5.1.2.) Concern #1: The same Section 6.5.1.2 seems to say that any scheme starting with the "web+" prefix gets something of a pass with regard to security: "If the registerProtocolHandler() method is invoked with a scheme that is neither a whitelisted scheme nor a scheme whose value starts with the substring "web+" and otherwise contains only characters in the range lowercase ASCII letters, the user agent must throw a SecurityError exception." Tying security to naming seems like a bad idea. This is related to my question above: for example, are we expecting designated experts or IANA to engage in more thorough security review regarding "web+" schemes? Concern #2: Generalizing from my first concern, I think we've seen a move away from building semantics into names. RFC 6648, which deprecated the "x-" prefix in application protocol parameters, is one example of that direction. IMHO conventions like the special "Security-" prefix in HTTP header names are a bad practice, and the "web+" prefix in URI schemes follows the same path. As far as I can see, there's no strong justification for hardcoding here, and if folks think there is such a justification then it would be good to explain it in the HTML specification or elsewhere. Peter -- Peter Saint-Andre https://stpeter.im/
Received on Wednesday, 1 August 2012 18:37:30 UTC