Re: [Uri-review] Fwd: [Fwd: Registration of 'oid:' as a URI/IRI scheme]

[Larry Masinter <[e-mail]>]

The new IRI-bis draft proposes reserving the "authority" field in IRIs for internationalized domain names, and using punicode (rather than hex-encoded UTF8) in the transation of IRIs to URIs. This is to prevent alternative paths which sometimes would wind up presenting percent-encoded UTF8 of original host names to DNS.

 A review of existing registered URI schemes didn't find any where this would be a problem, but if "oid:" were to use "//" for a non-DNS "authority" field (which it does not currently) it would cause problems.

(Discussion of policy on [e-mail], please)

Larry
--
http://larry.masinter.net

-----Original Message-----
From: Graham Klyne [mailto:[e-mail]] 
Sent: Wednesday, November 25, 2009 11:18 PM
To: [e-mail]
Cc: "Martin J. Dürst"; Lisa Dusseault; Martin Duerst; [e-mail]; [e-mail]; Larry Masinter
Subject: Re: [Uri-review] Fwd: [Fwd: Registration of 'oid:' as a URI/IRI scheme]

John Larmouth wrote:
> I am sure we understand the issues and implications of comparison, and 
> for our purposes they are acceptable.  On the // issue, we have 
> oscillated on that over the production process, and our latest advice is 
> as recorded in 03 - we use only "oid:/Alerting/....." for example.   
> There *is* a use for relative OIDs (and they *are* defined in the 
> Recommendations | International Standards), but we were *not* planning 
> on allowing those in the IRI scheme, as establishing the context for the 
> relative OID/IRI is more difficult than in a controlled protocol 
> environment.

(Scheme reviewer hat OFF...)

I would say that if you use a URI form with '/'s, you cannot prevent others from 
using relative forms in ways defined generally for URIs, which may or may not be 
the same as (or isomorphic with) relative forms defined by the OID 
Recommendations.  I think it could be confusing if two different ways of doing 
relative OIDs were potentially available (even if not actually blessed by the 
specification).

The URI spec provides some guidelines for establishing the context for relative 
URIs, but these are necessarily partial for the reasons you indicate.

My comment about using '//' was because the first path-segment of your OID URI 
seemed to perform the same function as the "authority" in a URI.  I can't tell 
if it truly does.

Martin:  from my recollection of when I looked into this previously, I think 
it's OK for a URI scheme using the relative path constructs to *not* have an 
authority component, hence is not *required* to start with '//'.  My take would 
be that the leading '//' should be used if[f] the following element is an 
authority in the (loosely defined) sense of RDF 3986.

#g