Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

[John C Klensin <[e-mail]>]

Nico,

(top post)

Referring to Barry's recent note on the URN mailing list and my
response, are you referring the URNs-the-category or
urns-the-scheme?  If the former, I agree that I don't care, no
one else should either.  More important, the new I-D isn't about
that.   If the latter, then I expect that you really should go
through the registration procedure described in RFC 3406 if you
have not done so.

    john


--On Saturday, 19 April, 2014 17:38 -0500 Nico Williams
<[e-mail]> wrote:

> On Sat, Apr 19, 2014 at 7:59 AM, John C Klensin
> <[e-mail]> wrote:
>> That set of distinctions is not just pedantry.  If "URN" mean
>> whatever someone claims it means at a given moment, then we
>> don't have a specific category of identifier, we just have a
>> very generic term for some variety of identifier.  For the
>> information it contains, one might as well have the above
>> statement read "UPC code for a can of baked beans is an
>> Ironduck".
> 
> In GSS land we've switched (for new interfaces) from using
> ASN/1 OIDs to  using URNs.  Our OIDs name no objects and our
> URNs no resources. They are merely identifiers with reasonable
> namespaces and name allocation policies.  URNs are much easier
> to use for this purpose (one look at how the GSS-API C
> language bindings handle OIDs should make this clear!).  Is
> this an abuse of URNs?  Does/should anyone care?  IMO: "no",
> and "no".  But it helps to have registered identifiers, so we
> can find the specifications (or at least some information)
> that describe their semantics.  Or perhaps our uses of
> OIDs/URNs do in fact name objects/resources, if we give
> specific behaviors/semantics the honor of being
> objects/resources.
> 
> For me, all that matters when it comes to URNs is that we
> agree to namespace partitioning and registries for those uses
> that warrant them.  If you want to call URNs "Ironducks", so
> be it.