- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Mon, 23 Jan 2012 10:57:26 +0900
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Larry Masinter <masinter@adobe.com>, David Booth <david@dbooth.org>, Robin Berjon <robin@berjon.com>, "www-tag@w3.org List" <www-tag@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>
On 2012/01/23 3:54, Julian Reschke wrote: > On 2012-01-21 06:53, Larry Masinter wrote: >>>> I'm not sure what the difference would be between having e.g., >>>> "web+acme:hello" and "web:acme:hello", except for a multi-level >>>> structure where potential inventors of a new protocol/scheme get more >>>> confused than necessary. >>> ... >> >>> The difference is mainly process: "web+" needs coordination with and >>> approval >>> by the IETF IRI WG, while "web:" is simply one additional new URI >>> scheme. >> >> The process is mainly irrelevant (sure, you might have to update the >> RFC twice, but in the IETF, decisions are made by rough consensus of >> the internet community, the "working group" doesn't approve.) > > "process is irrelevant" made me smile; after all we need to follow the > process to make a change like this. Also, the URI scheme registration > spec is a work item of the IRI WG, so I don't quite see how to change it > without the WG agreeing (and yes, "approval" was the wrong term here). It's 'irrelevant' in the sense that we can make it work. What's important is that we (browser makers/html5 WG/IRI WG, and on a higher level, W3C and IETF) agree on what to do. >> The issue mainly is whether you follow the generic hierarchical syntax >> and can use all URI parsing libraries if there's an 'authority' that >> you want to process differently than the path. >> >> for >> web+blah://a/b/c >> a is authority, path is /b/c >> >> but for >> web:blah://a/b/c >> there is no authority, path is blah://a/b/c > > Good point. I have thought about the problem of the first prefix like +web making it difficult for more prefixes to work. That could be alleviated by defining the prefix matching algorithm to look at prefixes at the start or after a "+", i.e. a regular expression like that: /(^|\+)web\+/. But I prefer that the information is added to the registry rather than to the name, because that's more flexible. Regards, Martin.
Received on Monday, 23 January 2012 01:58:03 UTC