Re: HTML5 proposes introduction of new family of URI schemes

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