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

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Apr 2014 16:13:44 +0200

On 2014-04-14 15:11, John C Klensin wrote:
> ...

One remark:

I don't think it's helpful to mix *this* discussion with the 
WHAT/W3C/IETF discussion about the "URL specification" (which 
essentially is about error-tolerant parsing)

And one question:

If you followed this path, would you still be able to use 
RFC3986-conforming libraries to handle URNs?

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Apr 2014 09:11:18 -0400

Hi.

It seems wise to call the attention of this broader group to
something that is going on in URNBIS (and more generally).
This message is a personal opinion.  It summarizes some
discussions in and around that WG but is not an attempt to
report on any sort of consensus.

RFC 3986 on Generic URI Syntax was an attempt to create a
general syntax (and, despite its title, partial semantics) for
an extremely general set of resource identifiers, using
experience with and developments from URLs as a starting point.
The general URI concept was intended to including URLs, URNs,
and possible future types.  That approach worked for URNs as
long as they preserved the very narrow definitions and syntax of
RFC 2141 but without taking advantage of any of the provisions
for extensibility ("future use") in that specification.

In the nearly 20 years since RFC 2141 was published, experience
with URNs in various communities has demonstrated the need, with
some URN types (NIDs), to be able to specify operations or
retrieval of metadata as well as objects and for partial
retrieval or other operations on either metadata of the objects
themselves.  At the same time, there have been forceful
discussions in information science, library, museum, and
publisher communities about the fundamental differences between
locators and names (which much of that community calls
"identifiers", excluding locators from that category) and the
disadvantages of mixing the two concepts.  That might be mostly
a theoretical issue except that the URNBIS WG has found it
impossible to define the functionality it needs while remaining
within the syntax and semantic constraints of RFC 3986 (at least
without creating obvious and very ugly kludges).  

The WG is now considering
draft-ietf-urnbis-urns-are-not-uris-00, which proposes to
separate URNs from RFC 3986, presumably leaving the latter with
URLs and name-like things that are not URNs.   It may be worth
noting that there is now work in W3C and WHATWG on a new URL
definition.  The intent of that work includes eventually
superceding 3986 (and 3987), at least for URLs, so there are
multiple forces working to dismember RFC 3986.  However, the
URNBIS draft is intended to narrowly focus on the needs of URNs,
rather than trying to boil the URI ocean.

Those who are interested in this topic should probably take a
look at the draft and the discussions during the last week or so
on the URN mailing list
(http://www.ietf.org/mail-archive/web/urn/).   That list has
been fairly low-volume, so looking at those messages should not
be burdensome.  Discussion should also occur on that list unless
there are very broad issues that belong here.

thanks,
   john

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Apr 2014 10:35:48 -0400

> essentially is about error-tolerant parsing)

Agreed (although I would characterize parts of that discussion
differently).  The draft is strictly about the URN issues and
doesn't do that.  I just wanted to provide a little extra
context about other things that are going on to head off a
conversation about how 3986 must be inviolate ... a discussion
to which those other discussions would be relevant.

> RFC3986-conforming libraries to handle URNs?

Depends on what that means.  For a URN NID that is
2141-conformant (a small subset of what 3986 allows) any library
that can handle it today will handle it after this change.  But
what is driving this change is not theory, it is a need for new
functionality that just doesn't fit into the locator-oriented
3986 model.  That new functionality will require either new
syntax or old syntax with different semantics than those
specified in 3986.  Just as there is no such thing as a
3986-conforming library that can completely and generally handle
queries (other than parsing the query away from other components
and dispatching it properly), such libraries are not likely to
be able to fully process URNs.

Another piece of that issue is that comparison of two URNs for
equality is,  in the general case, a rather different kind of
operation than comparison of two URLs; I would not expect a
URL-based algorithm (e.g., a RFC3986-conformant library) to be
able to get URN comparisons right, at least without NID-specific
action routines.

I'm being a little vague about this only because the WG hasn't
gotten into the syntax to be used for those new functions.  I
think every effort will be made to keep as much compatibility as
possible, at least short of horrible and obvious kludges, but
how far 3986 libraries can be pushed will depend on those
decisions.

Some of this is explored from a slightly different perspective
in a few recent notes on the WG mailing list; please have a look.

best regards,
    john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 15 Apr 2014 20:28:43 +0900

Hello John, others,

> report on any sort of consensus.

First, it may help to give a direct pointer to an actual draft:

http://www.w3.org/DesignIssues/ModelConsequences

> and possible future types.

For crucial background reading, please see
http://www.w3.org/DesignIssues/ModelConsequences.
Please don't come back here before you have read it!

> That approach worked for URNs as

Please have a look at 
http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/. This was 
worked out and written in collaboration with people from the IETF and 
from the library community.

> disadvantages of mixing the two concepts.

When it comes to books, and therefore in the library community, such a 
distinction is very natural. But there are still many use cases where it 
may make sense to be able to use one or the other kind of identifier in 
the same field. That's what URIs are all about.

To use an (of course incomplete) analogy, it's a bit like the Internet 
and IP numbers: Before the Internet, there were various networks, and 
they used various different ways to identify their nodes. The Internet 
integrated them into a single address space, leading to great network 
effects. URIs do very much the same, just on a different level.

> That might be mostly

Your draft in question mentions quite a few requirements, but doesn't 
discuss at all how they would lead to kludges. Actually reading through 
the requirements, except for a couple of them, I have difficulties 
seeing even a shadow of needs for separate syntax. The conclusion of 
your draft comes out of the blue if it were not for the title.

> multiple forces working to dismember RFC 3986.

As Julian already said, the WHATWG work is of a completely different 
nature and cannot and should not be used as a justification for creating 
more confusion.

> However, the

Focusing narrowly on perceived differences in a specific case isn't the 
way to move forward.

> there are very broad issues that belong here.

Trying to split URI syntax is to the Web as e.g. claiming that servers 
and clients should be assigned different types of IP addresses. As such, 
this is in and of itself a broad issue that shouldn't be left to a list 
with limited coverage.

Regards,    Martin.

---

From: Graham Klyne <[email-masked]>
Date: Tue, 15 Apr 2014 14:18:46 +0100

Hi John,

I've just taken a look at 
http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00, and have some 
comments.

I find myself asking what is gained by removing URNs from the scope of what we 
call URIs?

At heart, the argument seems to be that not all locators are good names, and not 
all names are useful locators.  I can't disagree with that.  But that's not the 
same as saying all locators are not good names, or, conversely, all names are 
not useful locators.

An example that comes to mind is the use of DOIs for academic research outputs, 
and in particular for research data sets (e.g. Datacite [6]).  DOIs are 
conceived as names, and have the appropriate management processes around them 
applicable to names.  But I have observed that in recent times, the preferred 
form for presenting DOIs to the Web has increasingly been in the form 
"http://dx.doi.org/..." or similar (see also: [1]).  I think this exemplifies 
something that MAY be used as both identifier and name.

One of the goals and strengths of URIs in the web has been that they encompass 
other systems of identification [2].  A key notion is that for some thing to be 
"on the web" it should have an assigned URI (or several).  URNs regarded as a 
form of URI allow things that are named by other means, such as ISBN, DOI, etc., 
to be "on the web".  http://tools.ietf.org/html/rfc2141 (appendix A) alludes to 
this by noting "The URN syntax has been defined so that URNs can be used in 
places where URLs are expected" (terminology that predates RFC3986) - so there 
is some recognized value here in being able to use names as URIs.

For the Web, blurring the distinction between names and locators enables an 
incremental deployment of "follow your nose" information discovery, which in 
turn enables information discovery at a scale far beyond that which can be 
encompassed by any single managed namespace.  Particularly when we consider a 
web of agents (and things), where we can create names that are also machine 
actionable without prior bilateral or multilateral agreement (beyond the 
existing ones that underpin the web itself).  Ed Summers (who, among other 
things, put the LoC subject headings on the web [4]) offers this example [3]:
[[
One of the benefits of linking data in this way is the “follow your nose” 
effect. When a person in their browser or an automated agent runs across the 
creator in the above triple they are able to dereference the URL and retrieve 
more information about this creator. For example when a software agent 
dereferences a URL for NISO.
[...]
This ability for humans and automated crawlers to follow their noses in this way 
makes for a powerfully simple data discovery heuristic. The philosophy is quite 
different from other data discovery methods, such as the typical web2.0 APIs of 
Flickr, Amazon, YouTube, Facebook, Google, etc., which all differ in their 
implementation details and require you to digest their API documentation before 
you can do anything useful. Contrast this with the Web of Data which uses the 
ubiquitous technologies of URIs and HTTP plus the secret sauce of the RDF triple.
]]

At the level of technical implementation, the distinction between names and 
locators is, if not artificial, not as hard-and-fast as a fixed distinction 
(such as requiring that URNs are not URIs) would suggest.  You point out that a 
key feature of names is that their meanings persist.  Tim Berners-Lee has 
pointed out [5] that naming is a social and contractual issue, and that 
persistence is really a quality of service matter rather than something 
fundamentally apart from location.  In summary, the qualities you require of a 
name *could* be applied to many forms of URI, especially http: URIs, subjected 
to appropriate policies and management practices.

In conclusion, I am not seeing any practical way in which declaring URNs to be 
not-URIs actually helps to achieve the goals of URNs.  I don't see any specific 
constraints imposed by RFC3986 that are inimical to being names.  I'm not seeing 
any legal aspect of a URN (per http://tools.ietf.org/html/rfc2141) that isn't 
also allowed in a generic URI.  (I think there are other reasons why URNs have 
not enjoyed widespread uptake, such as unnecessarily restrictive syntax, and in 
some cases an over-strict interpretation of persistence.)

As they stand, having URNs as part of the URI "family" means that we have an 
assured way of using names that do satisfy the stated properties in a way that 
their referents may be first-class members of the class of entities that the 
Web, in all its richness, can describe.

...

Nits: the RFC3986 link in the body text at 
http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00#section-3 is 
incorrectly linked.

#g
--

[1] http://www.doi.org/doi_handbook/2_Numbering.html#2.6

[2] http://www.w3.org/DesignIssues/Axioms.html#uri

[3] http://inkdroid.org/journal/2008/01/04/following-your-nose-to-the-web-of-data/

[4] http://id.loc.gov/authorities/subjects.html  (nee lcsh.info)

[5] http://www.w3.org/DesignIssues/NameMyth.html

[6] https://www.datacite.org

On 14/04/2014 14:11, John C Klensin wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Graham Klyne <[email-masked]>
Date: Tue, 15 Apr 2014 14:28:48 +0100

John,

Further to my other comments...

On 14/04/2014 15:35, John C Klensin wrote:
> ...  But
> specified in 3986.

Maybe this is part of what is missing from your draft.  RFC3986 semantics are 
pretty minimal/malleable, so I'm struggling to understand what you might need to 
add that violates RFC3986.  (The main possible problem I can see would be 
possible interference with relative reference resolution, but that's not a 
problem if you avoid using '/' - which urns currently do)

> ...  Just as there is no such thing as a

> able to get URN comparisons right, at least without NID-specific

So there's nothing new there.  RFC3986 parsing is just a start - URI schemes all 
tend to have their own specific behaviours.  (Which is part of why there is some 
push-back against arbitrary introduction of new schemes.)  I'm not yet seeing 
the problem of adding NID-specific action routines as long as they don't vilate 
(minimal) RFC 3986 constraints.

#g
--

---

From: Larry Masinter <[email-masked]>
Date: Tue, 15 Apr 2014 16:25:36 +0000

The only thing that makes something a name 'persistsent' is the existance of a name resolution service or method which persists.
The syntax or namespace is irrelevant.  'persistent' isn't binary, it's just "how long". Everything has a life-time.

http://masinter.blogspot.com/2010/03/ozymandias-uri.html

The meaning of a URI depends on the agreement of the community of a way of resolving URIs of that form.
http URIs meant using http/0.9, 1.0, 1.1, and now extended to encompass SPDY and HTTP/2.  

Nominally, a URN is a URI that has some organization/resolution authority/resolution method, where the authority is believed to be persistent, and available in the future to help resolve disputes, should they arise.  

So when A communicates with B and wants to talk about something they both can see (a 'resource') A uses a URI or URN or URL. And B understands what A meant because they both agree on what the UR* refers to. As the time between A sending and B reading and interpreting grows, the more important the persistence of the method by which B will understand  what A meant.

Is it time to revive http://tools.ietf.org/html/draft-masinter-dated-uri and finally get it to RFC?

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Apr 2014 20:38:10 +0300

I disagree strongly.

A URI is any string that fits in the URI slot in existing protocols
and will continue to be so regardless of decisions made here.

We should redefine the syntax of URIs to be a label followed by a
colon followed by any sequence of non-whitespace characters.

URI = label ':' anything

label = [a-z, 1-9, A-Z] +
anything = [not-whitespace]*

That should give the URN world more than enough scope. All they need
to do is to make sure their URN encoding escapes significant
whitespace which is probably an essential success criteria in any
case.

The syntax I give is pretty much the definition of a URI used in
pretty much all code that attempts to turn text into hyperlinks that
is not limited to http and https.

-- 
Website: http://hallambaker.com/

---

From: John C Klensin <[email-masked]>
Date: Tue, 15 Apr 2014 13:47:22 -0400

Hi.

Just wanted to tell folks that I'm on a very poor connection (if
on at all) for the next couple of days and probably won't be
able to give careful answers until Thursday and probably should
not try.  But one very quick observation in response to part of
Larry's note...

--On Tuesday, 15 April, 2014 16:25 +0000 Larry Masinter
<[email-masked]> wrote:

> The only thing that makes something a name 'persistsent' is
> the existence of a name resolution service or method which
> persists. The syntax or namespace is irrelevant.  'persistent'
> isn't binary, it's just "how long". Everything has a life-time.
> 

I think the above largely misses the point and that, in a sense,
your blog posting illustrates the point although not in the way
you probably intend.   "Persistent identifier" entered the IETF
vocabulary a long time ago but may not be very look terminology.

Some objects -- like stone statues if one doesn't care whether
they remain intact and standing-- have very long life
expectancies.  Others, like people, have shorter ones.  But URIs
(with or within including URNs) aren't objects, they are object
reference that, like most good references, involve some degree
of abstraction.  Now, "Ozymandias" is a very long-persistent
reference.  It isn't the object.  It is a somewhat ambiguous
reference because it can refer to the statue, the poem, your
blog posting, and probably several other things, but has a long
duration, perhaps one that is long enough to survive the objects
it references (just like titles of long-lost books).   But, as a
reference, it is that persistent because it is not bound to a
retrieval mechanism that has its own persistence properties. 

Whatever its other properties,
http://masinter.blogspot.com/2010/03/ozymandias-uri.html
is lousy as a persistent identifier.  It depends on the
availability of "http" (or something called that) as a retrieval
mechanism.  It depends on there being a DNS, on there being a
TLD named "com" an SLD named "blogspot", and both of them having
certain properties of which HTTP can take advantage.
"Ozymandias", and even the potential URN
urn:poems:Shelley/Ozymandias are more persistent because they
represent a higher level of abstraction and are not tied to
either a location or a retrieval/access method.  Use of a
hypothetical ISPN (International Standard Poem Identifier) in
the form urn:ispn:NNNN-NNNNNN-NNNNNNNNNNNNNNNNNNNN might or
might not be more persistent: it would be an exact identifier of
something and makes equivalence comparison more feasible and
less ambiguous, but it is probably tied to a database to
actually identify an object and such databases may be more or
less available and persistent than access methods and/or the DNS
(which is, after all, just another database).

Regardless of what one calls them, I suggest that
access-method-dependent identifiers (http:...,
NineTrackTape:??42.3744°?N,?71.1169°?W?123456 (where "?"
represents one or more carefully-chosen delimiters that may not
have RFC 3986 semantics), ...) are different kinds of creatures
than either the objects to which they refer or names of those
objects that are not, in the sense of the above, method or
location-model dependent.

More soon.

    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 15 Apr 2014 14:40:46 -0400

Actually, we don't disagree on anything but language and tactics.

Specifically, the underlying problem is that there are semantic
(and maybe syntax) constraints in RFC 3986 that make it, and its
definition of "URI" unsuitable for some plausible and important
class of identifiers (especially those, or a subset of them,
whose "methods" are not tied to a particular retrieval or
processing protocol (note that "SIP:" and "Mailto" are really no
different from "http" in that regard).

One can avoid recognizing that it is problem and try to force
all identifiers into the Procrustean bed defined by 3986.  That
isn't working well.  Its ultimate result is almost certain to be
the development of object identifier standards away from the
IETF and W3C and the need to adapt to that bed.   Indeed, that
has already occurred; note the Handle System and the
closely-related DOIs.  

Or one can recognize the problem and try to deal with it.  It
seems to me that there are several ways that problem can be
addressed, in more or less decreasing order of drasticness.

(1) Discard RFC 3986 entirely, adopt the syntax convention you
suggest (URI = label ':' anything), and leave each method
definition to its own devices.

(2) Revise and replace 3986 in a way that removes all of the
semantic definitions and constraints, leaving only the generic
syntax.  I think that the result would be workable but, unlike
the "every method defines its own syntax within 'anything'"
model above, I can't prove it.  And, having explored that
option, it turns out that removing the subtle semantic
constraints from 3986 is not easy.  (See the thread in the URN
mailing list for more about this.)

(3) Redefine 3986 as applying only to URLs.  If you have a URI
type (i.e., a method) and define it as a URL, you get to
incorporate 3986 by reference and use its syntax and semantics
without repeating them.  If you don't make that declaration, you
are on your own, much as in (1) above.

(4) Come up with a new typology of URIs and then remove one or
more of types from the scope of 3986.  Of course, as Larry's
insistence that there is really no such things as a persistent
identifier shows, coming up with such a typology and reaching
agreement about it is not straightforward.

(5) Remove URNs from the scope of 3986, leaving everything that
doesn't use the pseudo-method "urn:" within the scope of 3986
until and unless they demonstrate why they should be removed too.

Approach (5) is the one suggested in the draft, not because I
think it would be optimal in the best of all possible worlds,
but because it appears to be something that the URNBIS WG can do
and that would allow it to move forward.

FWIW, the practical difference among some of those approaches is
ultimately the old issue about the difference between
inclusion-based and exclusion-based models.  RFC 3986
effectively says "all identifiers are URIs and should (or must)
conform to this model.  As soon as we get to "except those that
don't", one can either identify those that don't or those that
do.  Of course, if we were to shift to the much more generic
model of (1), number of things that would need to be excluded
would presumably be far fewer.

best,
   john

--On Tuesday, 15 April, 2014 20:38 +0300 Phillip Hallam-Baker
<[email-masked]> wrote:

> I disagree strongly.
> 
> A URI is any string that fits in the URI slot in existing
> protocols and will continue to be so regardless of decisions
> made here.
> 
> We should redefine the syntax of URIs to be a label followed
> by a colon followed by any sequence of non-whitespace
> characters.
> 
> URI = label ':' anything
> 
> That should give the URN world more than enough scope. All
> they need to do is to make sure their URN encoding escapes
> significant whitespace which is probably an essential success
> criteria in any case.
> 
> The syntax I give is pretty much the definition of a URI used
> in pretty much all code that attempts to turn text into
> hyperlinks that is not limited to http and https.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Apr 2014 21:58:26 +0300

> Actually, we don't disagree on anything but language and tactics.

I understood that. It is a specification so language is rather important.

I don't like the suggestion that the URI slot in the existing
protocols no longer includes URNs. But I am more than happy to toss
virtually the entire URI syntax out.

I am also rather suspicious of the idea that the difference between
URNs and URLs is that one is a name and the other is an index. Both
are both.

The real difference is that a URL must contains a DNS name and a URN
probably does not.

I don't believe in the 'persistent identifier' notion except for the
limited case involving SHA-256 and the like

> different from "http" in that regard).

Then replace RFC 3986 with one that says 'this is the URI syntax and
the semantics are defined by the scheme'.

I agree that tying http: to the HTTP protocol seems rather antiquated
now. Unfortunately NAPTR is also unhelpful.

> definition to its own devices.

That would be my choice if it meant less argument.

> mailing list for more about this.)

I would be fine with URLs being a syntactic subset of URIs.

Possibly we could define the method://<domain>/<stuff> and
method:<account>@<domain><stuff> patterns as the 'URL patterns and
declare all else to be a URN.

> are on your own, much as in (1) above.

OK

> agreement about it is not straightforward.

I don't think that the persistent identifier problem is insoluble. I
just haven't seen a convincing solution yet.

And in the real world any persistent identifier scheme has to cope
with copyright and kiddie porn takedown issues. I have an interesting
attack on the BitCoin blockchain. The attacker encrypts some kiddie
porn and dumps it into the blockchain. Then a little while later they
drop the key into the blockchain. Then when the chain is final they
call the cops, anyone with a bitcoin wallet is now carrying kiddie
porn.

Hows that for a DoS attack?

> and that would allow it to move forward.

Removing URNs from scope is not quite the same thing as saying that
they are not URIs.

> would presumably be far fewer.

We split specs apart all the time. Just present this as a piecemeal
rollout of URI/2.0 doing the URN space now and the locators 'at a
later time'.

I don't want to deal with the locators at the moment because the only
way to fix locators properly is to make use of DNS in ways that people
tell me are currently impossible due to the infrastructure constraints
right up to the point when I suggest changes when they tell me that
the protocol is perfect[1].

And of course for those of us who built an Internet scale PKI twenty
years ago that is working pretty well all things considered[2], the
whole point of deploying DNSSEC was always to enable security policy
information to be deployed through the DNS. So I would not want to
open up discussion of URL/2.0 right now.

[1] Fortunately fixing the last mile issue of DNSSEC forces us to fix
the client-resolver loop and so does Edward Snowden.

[2] Folk who disagree need to sign the DNS root with a key longer than
RSA1024 before throwing stones at others.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Apr 2014 16:39:56 +0200

> The real difference is that a URL must contains a DNS name and a URN

Not true. It doesn't need to be a DNS name.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Apr 2014 10:42:07 -0500

> Not true. It doesn't need to be a DNS name.

The difference is blurry, but I like to think of it as: a URN is just
a name and there needn't even be a mechanism to resolve one to a
resource -- heck, there needn't even be a resource.  Whereas a URL is
a name that indicates how to resolve it in order to locate a resource;
the location part might not -need not- be stable.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Apr 2014 18:04:40 +0200

> resource -- heck, there needn't even be a resource.  Whereas a URL is

If "it" has a URN then "it" is a resource. By definition.

> the location part might not -need not- be stable.

But it's good as it is.

A URL is a locator which might be a stable name as well.

A URN is a name that may act as a locator later on.

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Apr 2014 19:13:02 +0300

> Not true. It doesn't need to be a DNS name.

Why bother with anything else? Its all legacy now or going to be soon
enough. X.500 has never been a viable directory. Telephone numbers are
the only other widespread locator.

We have some names that don't use the URN prefix and we have some
stuff like about: and data:

But if we take a look at this as a semiotics problem. We have Noh's
three classes:

Firstness: The identifier is the thing identified (e.g. data)

Secondness: The identifier is an index of the identified (http, mailto: etc.)

Thirdness: The relationship between the identifier and identified is
purely conventional (i.e. arbitrary, i.e. a 'name').

It does not have to have a URN prefix to be a name. Nameness comes
from whether it has the property of thirdness or not. news: URIs have
always been URNs, so are message IDs.

[OK I'll accept IP address literals and I will accept DNS names that
may not resolve on the Internet due to split horizon DNS.]

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Apr 2014 11:21:04 -0500

> the only other widespread locator.

With the caveat that "DNS name" need not be the same as a hostname
(FQDN).  It might be a domainname for use as starting point for
service location.

Can we use URLs for geocaching?  For locating resources on satellites?  ..

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Apr 2014 19:30:52 +0300

> Can we use URLs for geocaching?  For locating resources on satellites?  ..

We can certainly use URIs. The issue here is whether we claim it has
'name like' semantics or 'locator like'.

Since most of the people who talk about names don't seem to be
familiar with the relevant literature, I think the best approach is to
limit URLs to locators where we specify the naming infrastructure
(DNS, IP, hosts.txt) . That is a distinction we can agree on.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Apr 2014 11:44:32 +1000

I have to say that I'm sympathetic to the proposed outcomes, albeit for different reasons, perhaps.

We have two communities using a shared artefact (URIs) with vastly differing use cases and viewpoints about them. Managing this situation has already proven extremely difficult for the IETF, and it seems to me to be very pragmatic to cease forcing them to co-exist, constantly bickering about angels dancing on pins. 

While people don't want to consider it in-scope for this discussion, I also think that doing so will make the situation with WHATWG and W3C more manageable.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Graham Klyne <[email-masked]>
Date: Thu, 17 Apr 2014 03:57:37 +0100

> Is it time to revive http://tools.ietf.org/html/draft-masinter-dated-uri  and finally get it to RFC?

I think so.

But I also don't see sufficient head of unrequited need to get this progressed 
as a standards action.  YMMV.

My suggestion would be to request informational, maybe ISE, RFC publication with 
provisional URI scheme registrations.  That creates an available and persistent 
(sic) reference that developers might think about using if it meets a need (e.g. 
in Memento [1] implementations?).  Then, if it does become widely used, there's 
a ready point of departure for a standards action.

#g
--

[1] http://tools.ietf.org/html/rfc7089

---

From: Scott Brim <[email-masked]>
Date: Fri, 18 Apr 2014 10:48:21 -0400

> A URN is a name that may act as a locator later on.

I would be careful about trying to take the network locator/identifier
discussion into UR* space. A locator in the network gives you a network
attachment point, not the object attached to it. Also there are many
identifiers that are unrelated to any locators. The mapping to app space
isn't very good and using locator/identifier could produce confusing
results.

Perhaps you could think of URLs as naming "instances"?

Scott

---

From: Mark Baker <[email-masked]>
Date: Fri, 18 Apr 2014 11:19:56 -0400

> 'name like' semantics or 'locator like'.

Whether it's a name or a locator is not an intrinsic property of the
string, but depends solely upon the presence or absence of a local
resolution mechanism for that string.

A string that *you* might *today* call a "name", might already be a
"locator" to somebody who's rigged a private resolution service. Ten years
from now, that "name" might be a "locator" to all of us.

Mark.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Apr 2014 22:34:40 -0400

On Fri, Apr 18, 2014 at 11:19 AM, Mark Baker <[email-masked]> wrote:
> Whether it's a name or a locator is not an intrinsic property of the string,
> but depends solely upon the presence or absence of a local resolution
> mechanism for that string.
>

Which is exactly what I was saying.

For example, UPC code for a can of baked beans is a URN.

But if you go to Amazon you can use it as a locator, albeit mediated
via UPS rather than TCP/IP.

---

From: Scott Brim <[email-masked]>
Date: Sat, 19 Apr 2014 17:18:57 -0400

The inverse way of looking this is that identity-related functions can use
anything they want since they can treat it opaquely ... and do ... while
location-related functions are limited to tokens they understand the
semantics of.

---

From: Nico Williams <[email-masked]>
Date: Sat, 19 Apr 2014 17:38:58 -0500

On Sat, Apr 19, 2014 at 7:59 AM, John C Klensin <[email-masked]> 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.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 19 Apr 2014 17:44:56 -0500

>> from now, that "name" might be a "locator" to all of us.

Yes.  Consider a use of URNs as opaque identifiers of optional
behaviors.  Add a registry of such URNs listing their specifications.
But now they are both names and locators, since they can be used to
locate specifications in the corresponding registries.  Now, if
there's no way to automate this location, and/or if it's only useful
to implementors, then such URNs remain names.  Names for what?  For
behaviors.

> location-related functions are limited to tokens they understand the

Yes.  We could construct a URN namespace where location of
specifications via [IANA, say] registry lookups turns them into
locators.  Just not locators useful to most people.  In the end URNs
are really just opaque identifiers.  Some of them name real resources
(e.g., there's a way to name RFCs using URNs); some will not.  We
should not demand that every URN name a "resource" in that sense!

Nico
--

---

From: Barry Leiba <[email-masked]>
Date: Sun, 20 Apr 2014 11:17:12 -0400

Again, addressing just one point here:

Graham said this:
> DOIs
> are conceived as names, and have the appropriate management processes
> around them applicable to names.  But I have observed that in recent times,
> the preferred form for presenting DOIs to the Web has increasingly been in
> the form "http://dx.doi.org/..." or similar (see also: [1]).  I think this
> exemplifies something that MAY be used as both identifier and name.

> via UPS rather than TCP/IP.

I think both of these confuse the issue.  Given a name, we can often
turn it into a locator.  That's clear, and that's one thing that makes
names useful.  But I think we still need to keep in mind that the
names *aren't* locators.  If I can always take "urn:doi:xyz-abc",
transform it to "http://dx.doi.org/find/xyz-abc", and get a valid
locator for the thing named, that's great.  But it's still the case
that the former is a name and *not* a locator.  And if dx.doi.org goes
away at some point, the thing is still named by "urn:doi:xyz-abc",
even though I can no longer use that locator.

It's rather like using "Barry Leiba" to talk about me, and that's fine
as long as it's a reference.  But as soon as you need to *find* me,
you have to get a locator.  The locator might or might not contain my
name; it could be "[email-masked]", it could be my phone
number, it could be a URL for my web site, or it could be a suggestion
that you look here <http://www.the-craftsman-ale-house.com/> on a
Friday evening.

Again, for the purposes of abstraction, let's be sure to remember the
distinction, and to be clear about the scope of what we're discussing.

Barry

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2014 16:58:37 -0000

>transform it to "http://dx.doi.org/xyz-abc", and get a valid

It seems fairly ambiguous what a DOI is in practice.  It's defined as
an instance of the handle system (the only one that seems to have
gotten much traction), which has its own little-used lookup protocol.
There was a doi: URI defined in a draft which expired in 2003, and
which seems to to exist only as a Firefox plugin.

While DOIs are entirely reasonable URNs, the DOI group now wants
everyone to write the URN doi:10/123.456 as the URI
http://dx.doi.org/10/123.456.  While this makes them easier to embed
in web pages have have the links work, it also loses one of the
intended features of the URN, which that the resolution can be context
dependent.  This matters in practice, an institution with a library
would likely want to resolve DOIs itself so it can provide users with
local copies when possible rather than the original which may be
behind a paywall or otherwise hard to retrieve.

So you're right, they're different.  I could imagine something like a
thing that's a name, and here's the default way to turn it into a
locator if you don't have anything better, but that seems both complex
and vague.

R's,
John

---

From: Mark Baker <[email-masked]>
Date: Mon, 21 Apr 2014 01:41:56 -0400

On Sun, Apr 20, 2014 at 11:17 AM, Barry Leiba <[email-masked]> wrote:
> locator for the thing named, that's great.

We are not talking about transformation, and I don't consider it a
general solution to any known problem with URIs, at least not as
commonly discussed (primarily, a spec defining an equivalence mapping
between two URIs).

>  But it's still the case

There's nothing stopping that string from being used as a locator.

Even if a transformation based approach were used, all I need is
another scheme, say "doi2" that's defined so that all its URIs can be
transformed to an http scheme URI at dx.doi.org. Whip up a little
Javascript registerProtocolHandler with a one line string transform,
and whammo, doi2:xyz-abc is a locator for me.

Another configuration to consider - to John Levine's point - is using
intercepting proxies (or manually configured ones, for those not on
the library network) to, e.g. resolve http://dx.doi.org/xx.yy.zz to
some local copy stored at the library. I'm sure there are other
possible configurations too, that use a similar level of indirection,
perhaps using other mechanisms (DNS?).

So let's please forget about this "name" and "locator" stuff since
those labels are so context dependent as to be useless in any broadly
scoped discussion like this. There are only identifiers.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 21 Apr 2014 18:19:07 +0900

> scoped discussion like this. There are only identifiers.

Yes indeed. I occasionally get students making presentations based on 
outdated (but Japanese) material that makes a sharp name/locator 
distinction, or get asked by students about the difference between URLs 
and URNs.

I always explain that in the context of a traditional library (i.e. 
physical books), the distinction is very easy: When you want to 
borrow/read a book, you don't care which copy you get, because they all 
look the same, but in order to actually get a copy, you have to know 
where it is.

However, as soon as you move to the Web (or any other electronic 
system), things start to get blurred. Caching (in CDNs, in proxies, by 
your browser, in core memory,...) and similar tricks (multiple 
servers,...) produce lots of copies, but you for most purposes, you 
don't have to be concerned where they are, that's all handled "under the 
hood". Even where it's not, it's always easy to make it so (see examples 
above).

That's why library people used to see the name/location distinction as 
an absolute one, and there are still some applications with a strong 
tie-in to that model (which is alright by me), but why we should keep 
our infrastructure flexible to allow different models to coexist.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 21 Apr 2014 20:37:21 +0900

On 2014/04/19 21:59, John C Klensin wrote:

> --On Friday, April 18, 2014 22:34 -0400 Phillip Hallam-Baker
>>> A string that *you* might *today* call a "name", might
>>> already be a "locator" to somebody who's rigged a private
>>> resolution service. Ten years from now, that "name" might be
>>> a "locator" to all of us.
>>
>> But if you go to Amazon you can use it as a locator, albeit
>> mediated via UPS rather than TCP/IP.
>
> As Mark Nottingham suggested and I tried to elaborate, this
> particular discussion may be interesting (or not), but, in the
> current context, isn't worth the energy it takes.

Well, no, it's exactly at the very core of the issue. See below for more.

> First, a UPC code for a can of beans isn't a URN.  If an
> identifier for those were documented and registered as an NID,
> or if it were treated as part of an identifier sub-space within
> the "epc" NID specified in RFC 5134, _that_ would be a URN.

Okay up to here. Let's assume that done.

> As
> a URN, the defining materials would presumably come with a lot
> of information about what it was and what operations could be
> performed with it.  For a URN based on that UPC associated with
> a can of beans, those operations might include whether its
> purpose is just to distinguish one brand or can-size of beans
> from another or whether it can be used to retrieve a product
> (see below).

No. The URN/UPC just stands for the can of beans. What you can do with 
it depends on where you use it. Here's where Phil's example comes in 
very handy. Amazon will provide different operations on that URN than 
e.g. a service by the registration authority or by a manufacturer who 
doesn't ship directly to end users.

> whatever someone claims it means at a given moment,

That's not what we are talking about. The identifier still means the 
same. It's one and the same specific kind of can of beans.

> then we
> Even ignoring whether it is a URN or not, a UPC doesn't act as a
> UPS-mediated locator, any more than urn:isbn:0-88175-188-X is a
> TCP-medidated locator.  It is an identifier of an abstraction of
> a class of objects.  To get the object to your doorstep, it is
> typically necessary to resolve it to a different product
> abstraction, to a warehouse and location in it, to a
> shelf-picking mechanism, and so on, typically through several
> step before a particular can-instance is finally chosen, boxed,
> labeled, and handed over to UPS (or some other transit carrier
> whose choice might be another item in the list of
> abstraction-resolutions.

Of course. That's what I wrote about in a separate mail. Even for a 
simple "locator" such as "http://www.ietf.org", there are many very 
similar (although much less physically visible) steps involved. And as 
in the case of something like "http://www.ietf.org", the average user on 
average doesn't want to care much about all these intermediate steps.

> In addition, like many URNs (see my notes on the URN list),
> there are other useful questions that apply to the
> generically-named object and not to the particular can that
> might be located.  For example, "what is the size of the can
> associated with that code" is a question about the generic named
> object.  "What is the sell-by date" probably still doesn't apply
> to a particular can that needs to be located and retrieved
> before the question can be answered -- perhaps it is sufficient
> to locate a case of cans and to do so in an appropriate database.
>
> So I suggest they are still different from http-type URLs in
> more ways than the [retrieval] method.   But, again as Mark
> Nottingham pointed out, it may be that the greatest value of
> this proposed separation is to get around the situation of
> different communities talking past each other and being
> unwilling to accept each other's perspective and legitimacy even
> to the extent needed to have a real conversation.

No, we have had different communities talking past each other in the 
past, and have surmounted that very well. The problem with any 
separation is that it eliminates any potential benefit of being able to 
both URLs and URNs interchangeably where they are interchangeable. Of 
course they are not always interchangeable. But that's no reason for 
separation.

Regards,   Martin.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 21 Apr 2014 15:35:34 +0000

There's a problem with using 'locator' and 'name' as categories for strings -- strings are strings. Whether a string is a 'locator'  or 'name' depends on how it's used.  

That the same string can be used as a locator and a name is an important pun:  XML namespace names use IRIs as names, so that it's primary use is as a name, but it can also be used as a locator to find more information about the thing named. More generally, the "semantic web" uses URLs to name things, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-URI-Vocabulary -- easy allocation, and allows one to locate information about the thing named.

URLs can be persistent ('data:', and http://tools.ietf.org/html/draft-masinter-dated-uri )
and URNs can be as temporary as the URN namespace authority  urn:authority:authority-name-for-thing.

Do not confuse a location optimization used in locating (cache, proxy, web archive)  with the actual meaning. The actual meaning depends on how you would resolve disputes over meaning. 

Larry

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Apr 2014 15:53:00 -0400

--On Friday, April 18, 2014 11:44 +1000 Mark Nottingham
<[email-masked]> wrote:

> We have two communities using a shared artefact (URIs) with
> vastly differing use cases and viewpoints about them. Managing
> this situation has already proven extremely difficult for the
> IETF, and it seems to me to be very pragmatic to cease forcing
> them to co-exist, constantly bickering about angels dancing on
> pins. 

Mark,

The above is actually a slightly different version of what drove
me to propose the "separate URNs" change in the new draft.  As
you say, we have two different communities with different
assumptions, exemplars, and perceived needs.  The one thing they
have in common is that neither accepts and interprets the
examples of the other in the same way.  Indeed, each community
tends to reject the legitimacy of the position and arguments of
the other and often to be dismissive and as far as I can tell,
largely stops listening.  More on that below, but let me suggest
there are two separate discussions that we can have now:

(1) Whether to continue to try to defend a Grand Unified
"Uniform Resource Identifier" theory (and, in your words,
"shared artifact"), with each of those words meaning whatever it
does to the person who pronounces it, or to let the communities
you mention go off and develop solutions to their own perceived
problems.  The predictable consequence of the first is going to
be standards development elsewhere, rather than stopping what
some perceive as bad behavior... we are just past "stopping"
those communities with which some other community disagrees.

(2) The details of what the community that the draft identifies
as "content industries and memory organizations" need in URNs
and how to organize that information.  I will comment on that
subthread, but only on the URN list.

There is an additional potential discussion about what choices
we would make if we could turn the clock back to 1994 or 1996 or
about how things would have been defined in a better world
(perhaps turning some other clocks back to the 12th century or
earlier).  I think that discussion would be interesting and
educational, but that, for the IETF right now, it is just a
distraction, best injected into the two questions above only if
one's goal is to prevent progress.  Of course, some people may
disagree with that position and probably do.

Those who are not interested in the details of my thinking about
the first issue and the reasons why we are in this position can
safely stop reading now.

       -----------

Sadly, some of these same arguments --including the implied "I
am right, you don't count, and I don't need to listen" tone of a
subset-- go back to the original URI WG and some of the reasons
I shut it down in 1995 (and resolved, unsuccessfully, to stay
out of this area after that).  It has become clear in URNBIS WG
discussions that some of those in other communities sincerely
believe that RFC 3986 doesn't represent consensus, only an
example of how a determined minority can outlast and then
overwhelm others (and, from their point of view, reason and
experience).  

More recently, Martin cites a number of articles and says
"Please don't come back here before you have read it!".  Some
members of another community consider some of the statements in
those articles to be a big joke, a massive demonstration of lack
of understanding, or worse.  Other statements help demonstrate
that we aren't making progress (for example, the 1998 "Model
Consequences" document Martin cites identifies the "views of URI
syntax" as a contrast between the "name ':' anything" approach
that Phillip brought up as the only reasonable possibility and
"uniform sharing of URI syntax to the extent it may make sense".

What seems to be different now from a few years ago is that
people in some of those other communities have reached the point
of being willing to do their own standards work, reflecting
their perceived needs, because they view their needs as real and
based on real experience and the IETF community as hopelessly
paralyzed and not listening.    Independent of whether they are
in-scope, the WHATWG and W3C efforts, and maybe the lack of
consensus and diminishing energy in the IETF IRI WG, may be
symptoms of that trend.   

I'm still convinced that the IETF's experience, perspective, and
scope still have useful things to bring to this discussion.
Maybe I'm naive.  But it seems to me that the choice at this
particular time isn't between how broadly URIs can reach, how
much hair-splitting we can perform about "persistent" or
"locator versus object identifier" but about whether we can
separate things sufficiently to let the two (or more)
communities go their own ways under a broad IETF umbrella or
whether we prefer standardization work in this set of areas to
be done elsewhere, most likely (given trends in W3C and WHATWG
as well as in URNBIS) with most of the relevant groups agreeing
only the 3956 is not relevant to their needs and plans.

   john

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Apr 2014 08:59:49 -0400

the "epc" NID specified in RFC 5134, _that_ would be a URN.  As

     john

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Apr 2014 18:49:10 -0400

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
<[email-masked]> wrote:

> 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.

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Apr 2014 12:26:19 +0100

Phillip Hallam-Baker <[email-masked]> wrote:
> Why bother with anything else?

You might want to use an mDNS name, or a TOR .onion name, etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
West Wight, Portland, Plymouth, North Biscay: Mainly southerly or
southwesterly 4 or 5, occasionally 6. Slight or moderate. Occasional rain or
showers. Moderate or good, occasionally poor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Apr 2014 10:17:50 -0400

On Fri, Apr 18, 2014 at 3:53 PM, John C Klensin <[email-masked]> wrote:
> examples of the other in the same way.

I think the disagreement is over what counts as an example.

Back in the early days of URNs I remember a lot of people telling me
that naming 'was hard' but could not explain why and that 'only a few
people understand it' but not who.

After a while I got rather tired of that mode of argument and decided
that I won't accept any argument that is not stated within the four
corners of the message or cited directly.

> Indeed, each community

Well either a URN is a distinct class from a URL or it isn't.

One of the things that makes me rather suspicious about the argument
is that every URL is based on a name, that is either a DNS name or an
IP address both of which are names in tat the relationship between the
signifier and the signified is purely convention. (In the case of an
IP address the addresses are resolved via BGP)

Making a distinction between URIs that are based on a naming
infrastructure that is defined by the IETF and those that are not
seems to me to be a perfectly sensible approach for the IETF to take.

> those communities with which some other community disagrees.

I am not sure what the above means. I can't parse it.

The IETF has limited bandwidth, the Internet has 3 billion users. So
less than 1/millionth of the Internet population is currently active
in IETF. Decisions and standards are going to get made in many places.

Whether any grand unified theory can be defended depends on the claims
made. If the claims made are extensive then the theory is likely to
collapse. If the claims are weak then it can be defended but has
little impact.

> subthread, but only on the URN list.

This is the part that I always have problems with, the idea that the
structure or syntax of the identifier has any impact on whether it
meets requirements such as long term resolution.

The only URI that is guaranteed to resolve to the signified content
unconditionally is the DATA method.

The only URIs that are shorter than the signified data that can claim
to be permanent are indexical, in most cases based on one way
functions such as 'hashes', 'fingerprints' and 'digests'.

Its not the syntax of a naming infrastructure that gives it longevity,
it is the political and business context in which it operates.

> out of this area after that).

I don't think it was one side of the argument guilty of that.

Most of my objections to various URN schemes come from the confusion
of requirements and mechanism. If someone is saying that we must
recognize a set of URIs as 'special' because of a particular set of
requirements then I want to see a demonstration that

1) The particular set of requirements can be met

2) The distinction insisted on helps meet them

> It has become clear in URNBIS WG

Yep

> only the 3956 is not relevant to their needs and plans.

Which is precisely why I suggest dividing the world up into 'that
which the IETF is authoritative on' and 'that which the IETF is not
authoritative on'.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Apr 2014 09:51:16 -0400

On Wed, Apr 23, 2014 at 6:04 AM, Maurizio Lunghi
<[email-masked]> wrote:
> I am wondering if it is useful and maybe necessary to define what a 'persistent identifier' is .... as many of you said technology is mot persistent per se but policy underpinning the system can make persistent the identifiers and the service linked to them .... in the APARSEN project www.aparsen.eu in WP 22 we reached agreement with many experts about a list of criteria that a 'trusted persistent identifier system' must have and we could start from this work to define a broader consensus .... doing so in my view we  could clearly distinguish between a URN or URI and a PI ... does it sound reasonable?
>

People have been compiling wish lists for properties of names for 20+
years. The issue is not what people would want, it is what they can
get.

I can't take the 'urn' approach seriously until someone provides an
explanation of

1) How the persistence properties are to be achieved

2) Why a taxonomic distinction between URLs and URNs helps achieve the
persistence properties.

A name is by definition a signifier that bears only a conventional
relationship to the thing signified. In the case of DNS that
relationship is mediated by the DNS infrastructure.

There are only two ways to make an identifier persistent. The first
being to use an index rather than a name. SHA256(c) is a persistent
identifier for the content c. Which is what we use in the ni: scheme.

The second is to have a first come, first served registry that never
revokes previous assignments. Now one could imagine a whole new
infrastructure for establishing such a scheme. But really, wouldn't
anyone setting up such a scheme apply for a TLD?

So now imagine we have .pid which is a first come, first served
registry that never revokes an assignment or alternatively requires
the date to be inserted into the HTTP URIs.

I can give you a HTTP method identifier which is persistent using such
an infrastructure.

Now we can argue over whether the proposal I make is actually
practical. But I think it is at least as practical as all the
'persistent identifier' schemes based on a new registry.

The bottom line is that persistence is a qualified property of a
naming infrastructure, not a syntactic distinction.

If people want to argue further, I want them to put up and show HOW
their persistence scheme actually works. No more wish lists or
requirements for identifiers. I want to see how the scheme works at a
technical and political level to achieve the persistence requirements.

---

From: Maurizio Lunghi <[email-masked]>
Date: Wed, 23 Apr 2014 10:04:55 +0000

thanks

Maurizio Lunghi

> On 22 Apr 2014, at 16:18, "Phillip Hallam-Baker" <[email-masked]> wrote:
> 
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

---

From: Maurizio Lunghi <[email-masked]>
Date: Thu, 24 Apr 2014 08:25:30 +0000

Maybe I was not clear, but a wish list is to think that your technical solutions can be considered 'Persistent Identifiers'
First, in the digital preservation arena we consider that policy are more important than technology actually, all the digital preservation applications have a strong and well defined policy in support of their goals, technology will be migrated in the years. As you said, any technology can become a PI if supported by an appropriate policy and application.
Second, in our recent work we agreed on that a PI is not only a number or string, a PI is a service where to that code an information service is granted by a trusted agency with a defined mandate in time and for a specific user community, this is then case for all the most relevant PI systems like DOI, Handle, ARK, NBN, and for the emerging PI systems for people also. In our work a PI system is composed by a reliable technology, a trusted body offering the service, a policy and mandate by the user community.
That's why I have the impression that we should define criteria for a trusted PI system in another document, as we have done about the trusted digital repositories issue with RLG, OCLC, TRAC, OAIS, ISO16363 ....

thanks

Maurizio Lunghi
direttore scientifico
Fondazione Rinascimento Digitale
[email-masked]  
+393351396371

-----Messaggio originale-----
Da: Phillip Hallam-Baker [mailto:[email-masked]] 
Inviato: mercoledì 23 aprile 2014 15:51
A: Maurizio Lunghi
Cc: John C Klensin; Julian F. Reschke; Mark Nottingham; [email-masked]; Graham Klyne; General discussion of application-layer protocols
Oggetto: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

> I am wondering if it is useful and maybe necessary to define what a 'persistent identifier' is .... as many of you said technology is mot persistent per se but policy underpinning the system can ma…

People have been compiling wish lists for properties of names for 20+ years. The issue is not what people would want, it is what they can get.

I can't take the 'urn' approach seriously until someone provides an explanation of

2) Why a taxonomic distinction between URLs and URNs helps achieve the persistence properties.

A name is by definition a signifier that bears only a conventional relationship to the thing signified. In the case of DNS that relationship is mediated by the DNS infrastructure.

There are only two ways to make an identifier persistent. The first being to use an index rather than a name. SHA256(c) is a persistent identifier for the content c. Which is what we use in the ni: scheme.

The second is to have a first come, first served registry that never revokes previous assignments. Now one could imagine a whole new infrastructure for establishing such a scheme. But really, wouldn't anyone setting up such a scheme apply for a TLD?

So now imagine we have .pid which is a first come, first served registry that never revokes an assignment or alternatively requires the date to be inserted into the HTTP URIs.

I can give you a HTTP method identifier which is persistent using such an infrastructure.

Now we can argue over whether the proposal I make is actually practical. But I think it is at least as practical as all the 'persistent identifier' schemes based on a new registry.

The bottom line is that persistence is a qualified property of a naming infrastructure, not a syntactic distinction.

If people want to argue further, I want them to put up and show HOW their persistence scheme actually works. No more wish lists or requirements for identifiers. I want to see how the scheme works at a technical and political level to achieve the persistence requirements.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 24 Apr 2014 18:59:14 +0000

"data:" URLs don't have DNS names and aren't URNs.
"mailto:" URLs have domain names, but not in the //.../ authority field
"duri:" and "tdb:" URLs are 'permanent', but are arguably not URNs.

---

From: Edward Summers <[email-masked]>
Date: Fri, 25 Apr 2014 04:45:05 -0400

> While people don't want to consider it in-scope for this discussion, I also think that doing so will make the situation with WHATWG and W3C more manageable.

I agree that, as distasteful as it might seem, it’s quite important to discuss the organizational (and personal) politics involved, to the best of our ability, in a respectful and constructive way. Pushing them off the table is just a way of making them an implicit part of any work that we do, which can result in difficulty in interpreting decisions later on...which can be expressed as angels dancing on pins. If possible I would like to hear how the proposed changes could help make the WHATWG/W3C situation more manageable.

The proposed changes to URN seem largely centered on the needs of memory organizations, who are a third community at play here. I am worried that the current draft makes this community seem monolithic in its approach to persistent identifiers and URIs. The current definition of URN as URI has not prevented useful work on persistent identifiers] by memory institutions, notably ARK [1], Memento [2], OpenURL [3], info-uri [4], ISBN [5] and Version Navigation [6] and Dublin Core [7]. I see Larry’s work on things like duri as other examples of useful work that can be done without changing the relationship of URN to URI.

I have personally found the work that has gone into Web architecture, in particular Fielding’s work on REST, has been extremely useful in designing digital preservation systems at the Library of Congress. Taking the Web seriously has lots of real benefits when it comes to application development and sustainability since there is a great diversity in software implementations and maturity with regards to scalability.  I’m not saying there aren’t challenges, but if memory institutions want to continue in their societal role, they must learn to work with the grain of the Web, not against it. I’m thinking of the excellent work that organizations like the Internet Archive have started.

So, as it stands, I think the current draft [8] is too simplistic in its approach, and actually does a fair bit of damage to people in the field. If you would prefer to have specific comments I can try to do that but I am having trouble decoding the politics at play here.

//Ed

[1] http://tools.ietf.org/id/draft-kunze-ark
[2] https://www.ietf.org/rfc/rfc7089.txt
[3] https://en.wikipedia.org/wiki/OpenURL
[4] https://www.ietf.org/rfc/rfc4452.txt
[5] https://www.ietf.org/rfc/rfc3187.txt
[6] https://www.ietf.org/rfc/rfc5829.txt
[7] http://dublincore.org/documents/dces/
[8] https://tools.ietf.org/id/draft-ietf-urnbis-urns-are-not-uris

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 25 Apr 2014 16:41:39 -0400

> From: Larry Masinter <[email-masked]>
> 

Ooooh, that's a fascinating example!

One can consider a "data:" URI to be a URL, since it provides a way to
locate the referenced information (i.e., parse the URI).  Nonetheless,
it does not contain a DNS name or any other identifier of a network
resource.

And yet it's also a URN, because it is a persistent identifier of the
referenced information -- the association of the URI with the
referenced information never changes!

Dale

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 28 Apr 2014 08:42:13 -0400

> referenced information never changes!

What you seem to be implying is that the term 'name' be defined by
whether or not it meets the requirements for persistence. That is a
terrible way to approach nomenclature.

The whole URN fiasco has been flawed from the start because names are
not persistent by their very nature. Names are in fact the LEAST
persistent type of identifier.

I remember back in the day when some AI people misread some books on
hermeneutics and started talking about 'ontologies'. Many people
reading this are aware of the AI definition which is essentially a
sort of shared vocabulary of terms. But in philosophy an ontology is a
system of being. We are beyond mere epistemology and into considering
the nature of existence and being.

Yes there are passages in Heidegger that can support the idea that a
being is an intersubjective shared framework of communication. But
relying on Heidegger for definitions is always a mistake: His
significance lies in the novelty of his work rather than the clarity.

Again, there is a very longstanding literature in semiotics. If people
want to use terms like 'name' I suggest that they stick to existing
definitions rather than invent new ones.

At the very least we should agree that the term 'name' has an ordinary
meaning and that meeting or failing to meet some requirements that
might somehow be defined in an RFC is not a proper test of whether
something is a name or not.

The term name already has a definition in the IETF, that is why it is
called the Domain NAME System and not the Domain Locator System.

John did complain about a 'my way or the highway' attitude. Well on
this I am completely right and there is no room for argument: DNS
labels are NAMES sand anyone who wants to argue with that proposition
needs to be given a copy of Heidegger and a loaded pistol.

data URIs are not names, they are data.

If we convert from the semiotics terminology of 'signifier'
'signified' to labels and resources we get:

Type 1: Data :  The label is the resource value

Type 2: Index : The label is a deterministic function of the resource value

Type 3: Name : The relationship between the label and the resource is
determined by convention

Note here that the terms Data and Index are constructed in such a
manner that the resource is static, only a name can bind to a dynamic
resource. It follows that all URLs are names.

The reason that this URN thing takes so long is that people are
insisting on bad terminology which is fundamentally confused.

The term name does not imply persistence. It implies the very
opposite. We could have a useful discussion of persistent versus
ephemeral names. Larry's dated URIs are an example of persistent names
(as are John Mallery's Persistent Document Identifiers from 1994). But
equating name = persistent name is to commit to a fallacy.

In conclusion:

* The taxonomic distinction between URLs and URNs is meaningless. URLs
== URNs for all practical purposes. The people who attempted to make
the original distinction did not know what they were doing and they
still don't.

* No more URN requirements documents. If people want persistent
identifiers then they can write up a draft of requirements for
persistent identifiers. There is no point in having a requirements
document for a term introduced 20 years ago.

* Rather than discussing persistence as a binary quality, we should
treat it like we treat security and ask 'how much'.