Subject: Re: [Uri-review] New icon URI scheme vs new URN namespace

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 3 May 2010 15:37:44 -0700

I disagree with making general classifications.

URNs suffer a significant lack of public understanding and stigma (regardless whether it is justified or not). We are trying to get people to stop making distinctions between URNs, URLs, and URIs. The decision whether to register a new URI scheme vs. a new URN namespace must not be limited to whether it is practical to use a URN. I have a few use cases for a new URI scheme where a urn: prefix will pose a serious adoption problem because of lack of URN understanding (draft pending).

As for the icon URI scheme, it is up to the authors to decide if their scheme will suffer or benefit from using the urn: scheme and make their case for it.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of David Booth
> Sent: Friday, April 30, 2010 5:44 PM
> To: Pierre-Antoine LaFayette
> Cc: [email-masked]
> Subject: Re: [Uri-review] New icon URI scheme vs new URN namespace
> 
> On Fri, 2010-04-30 at 13:42 -0400, Pierre-Antoine LaFayette wrote:
> > In my provisional URI scheme registration request with IANA, my
> > reviewer noted that it may be preferable to use a URN namespace rather
> > than create a new URI scheme.
> >
> >
> > E.g.
> >
> > urn:icon:ext:pdf:small
> > urn:icon:mime:text:plain:64
> > urn:icon:unknown
> >
> >
> > instead of:
> >
> >
> > icon:.pdf;small
> > icon:text:plain;64
> > icon:unknown
> >
> >
> > I wanted to run this by the list to see what the general opinion is on
> > this matter. What are the advantages/disadvantages and limitations of
> > each? I'm not sure which is more appropriate for the icon URI's use
> > cases.
> >
> >
> > http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-ur
> > i-scheme-00.html
> >
> >
> I agree with your reviewer.  IMO, if there isn't a new protocol defined for it,
> there is no need for a new URI scheme.  URNs are intended for exactly this
> kind of thing.
> 
> 
> 
> --
> David Booth, Ph.D.
> Cleveland Clinic (contractor)
> 
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of Cleveland Clinic.
> 
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review

---

From: "Ray Denenberg, Library of Congress" <[email-masked]>
Date: Mon, 3 May 2010 18:50:51 -0400

"We are trying to get people to stop making distinctions between URNs, 
URLs, and URIs."

Could you clarify that sentence.  It seems to suggest that URN, URL, and URI 
all mean the same thing, and I'm sure that's not what you're trying to say.

--Ray

----- Original Message ----- 
From: "Eran Hammer-Lahav" <[email-masked]>
To: "David Booth" <[email-masked]>; "Pierre-Antoine LaFayette" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 03, 2010 6:37 PM
Subject: Re: [Uri-review] New icon URI scheme vs new URN namespace

> URNs suffer a significant lack of public understanding and stigma 
> (regardless whether it is justified or not). We are trying to get people 
> to stop making distinctions between URNs, URLs, and URIs. The decision 
> whether to register a new URI scheme vs. a new URN namespace must not be 
> limited to whether it is practical to use a URN. I have a few use cases 
> for a new URI scheme where a urn: prefix will pose a serious adoption 
> problem because of lack of URN understanding (draft pending).
>
> As for the icon URI scheme, it is up to the authors to decide if their 
> scheme will suffer or benefit from using the urn: scheme and make their 
> case for it.
>
> EHL
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 3 May 2010 15:54:45 -0700

I would agree to this request and add who "we" is in the sentence.  It
is not the
IETF, obviously, since the IETF recognizes that URNs are a class of URIs
with specific properties (e.g. persistence).

regards,

Ted

On Mon, May 3, 2010 at 3:50 PM, Ray Denenberg, Library of Congress
<[email-masked]> wrote:
> "We are trying to get people to stop making distinctions between URNs, URLs,
> and URIs."
>
> ----- Original Message ----- From: "Eran Hammer-Lahav" <[email-masked]>
>> (regardless whether it is justified or not). We are trying to get people to
>> stop making distinctions between URNs, URLs, and URIs. The decision whether
>> to register a new URI scheme vs. a new URN namespace must not be limited to
>> whether it is practical to use a URN. I have a few use cases for a new URI
>> scheme where a urn: prefix will pose a serious adoption problem because of
>> lack of URN understanding (draft pending).
>>
>> scheme will suffer or benefit from using the urn: scheme and make their case
>> for it.
>>
>> EHL
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 3 May 2010 16:10:41 -0700

I was referring to the recent discussion on this list about which term should be used (URI vs URL).

We have URIs, and they come in different flavors and colors. When we have a need to identify a new resource, we first look at the existing schemes to see if they are applicable. If not we propose new schemes. URN offers specific benefits and shortcomings. Their name is a shortcoming when it comes to getting the web developers community at large to recognize and use them. This doesn't make them less useful, but it does pose an adoption limitation.

The point I was trying to make it that just because something *can* be implemented as a urn: namespace, doesn't mean it *must* be. At the same time, I think the authors should explain why they think it should/shouldn't be.

EHL

> On Behalf Of Ray Denenberg, Library of Congress
> Sent: Monday, May 03, 2010 3:51 PM
> To: [email-masked]

---

From: Stu Weibel <[email-masked]>
Date: Mon, 03 May 2010 16:17:34 -0700

At the risk of dredging up the corpses of old arguments, I would suggest
that URNs do NOT have a property of persistence.  They are intended to be
managed as persistent identifiers, and are structured so as to make that
more straightforward, but identifier persistence has little to do with the
the identifier per se.  Rather, it has to do solely with the commitment of
organizations that adopt the responsibility for managing such identifiers
(and their enabling infrastructure) persistently.  The technology can make
that harder or easier, but assures nothing.  There is no intrinsic
persistence property.

stu

---

From: Ted Hardie <[email-masked]>
Date: Mon, 3 May 2010 16:22:01 -0700

> that harder or easier, but assures nothing.  There is no intrinsic

It is an inherent property?  No.  Is it a property that those requesting
to manage namespaces under the urn scheme sign up for?  Yes.
If you don't want that property, flagging your identifier with something
that will indicate that property is a bad idea.

In other words, I think we agree.

regards,

Ted

---

From: "Ray Denenberg, Library of Congress" <[email-masked]>
Date: Tue, 4 May 2010 10:16:35 -0400

Let me add my perspective.  I don't personally care about the "persistence" 
aspect, but for the sake of discussion let's say that URNs are persistent. I 
feel that it is the emphasis on persistence that causes the confusion that 
gets cited all the time between URNs and URIs.

I think that when people *describe* URNs as persistent, then others (who are 
trying to understand URNs) interpret this description as the *defintion* and 
say "ah, now I understand, URNs are just persistent URIs". And that's a 
horrible definition of URNs but unfortunately it's the one that you see more 
than any other.   It leads to preposterous statements like:

http://www.example.com/abc    is a URN, because it is persistent.
http://www.example.com/xyx    is not a URN, because it is not persistent.

The definition of URN should be along these lines:

"URIs have schemes.   'http:', 'mailto:', etc.   'urn:' is one of those 
schemes.   Thus a URN is a URI that begins with 'urn:' "  Then add whatever 
you want after that, about persistence or whatever you like.  But I really 
think it would help reduce confusion if whenever someone asks "what's a URN 
you begin with this.

--Ray

----- Original Message ----- 
From: "Stu Weibel" <[email-masked]>
To: "Ted Hardie" <[email-masked]>; "Library of Congress Ray Denenberg" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 03, 2010 7:17 PM
Subject: Re: [Uri-review] New icon URI scheme vs new URN namespace

stu

On 5/3/10 3:54 PM, "Ted Hardie" <[email-masked]> wrote:

>> URLs,
>>> to
>>> case

---

From: "Ray Denenberg, Library of Congress" <[email-masked]>
Date: Tue, 4 May 2010 16:48:13 -0400

> The point I was trying to make it that just because something *can* be 
> implemented as a urn: namespace, doesn't mean it *must* be. At the same 
> time, I think the authors should explain why they think it 
> should/shouldn't be.

But where do there exist guidelines to choose?  Thus, someone could say, 
"well, it should be a urn namespace, not a uri scheme, because it is a 
persistent identifier". And as we've seen that is certainly a debatable 
criterion at best.  Or -- and as we know anytime anyone proposes a new URI 
scheme there is always someone who explains how he may (and in fact should) 
accomplish what he is trying to do using http  -- the reason for proposing a 
urn namespace may be "because I really don't want to do this using http".

So, no, I'm not sure that requiring the author to explain why a urn 
namespace is requested alone solves a problem. I think there needs to be 
agreed upon criteria for choosing between a URI scheme and urn namespace, 
and then require the author to explain why one or the other is chosen, 
citing those guidelines.

--Ray