- From: Larry Masinter <masinter@adobe.com>
- Date: Thu, 26 Nov 2009 11:25:20 -0800
- To: Graham Klyne <GK@ninebynine.org>, "j.larmouth@btinternet.com" <j.larmouth@btinternet.com>
- CC: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Lisa Dusseault <lisa.dusseault@gmail.com>, Martin Duerst <duerst@w3.org>, "uri-review@ietf.org" <uri-review@ietf.org>, "larmouth@btinternet.com" <larmouth@btinternet.com>, "PUBLIC-IRI@W3.ORG" <PUBLIC-IRI@w3.org>
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 public-iri@w3.org, please) Larry -- http://larry.masinter.net -----Original Message----- From: Graham Klyne [mailto:GK@ninebynine.org] Sent: Wednesday, November 25, 2009 11:18 PM To: j.larmouth@btinternet.com Cc: "Martin J. Dürst"; Lisa Dusseault; Martin Duerst; uri-review@ietf.org; larmouth@btinternet.com; 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
Received on Thursday, 26 November 2009 19:26:10 UTC