Subject: Re: [urn] syntax and registration: a proposal

From: Sean Leonard <[email-masked]>
Date: Mon, 3 Nov 2014 01:52:49 -0500

On Oct 30, 2014, at 7:58 PM, Keith Moore <[email-masked]> wrote:

> On 10/30/2014 07:55 PM, "Martin J. Dürst" wrote:
>>>> What I'm pushing for is a spec that is sufficiently clear that the
>>>> relative resolution algorithm defined by RFC 3986 indeed applies to
>>>> URN URIs, even though the results it yields for most URN schemes might
>>>> not be very useful.
>> 
>> The relative resolution algorithm applies to any and all schemes (including URNs) where it is applied.
> 
> Sorry, that's just insane.  It makes no technical sense whatsoever. 3986 is simply incorrect, and needs to be obsoleted and move to Historic.
> 
> Keith

All of this frustration with relative references and URNs illustrates a general point:

Since relative references don’t make sense with URNs, URNs SHOULD NOT include slash / characters.

That is why it looks like urn:ietf:rfc:3986 and not urn:/ietf/rfc/3986.

In the case of a syntax like urn:/ietf/rfc/3986, a relative reference to “../std/1” makes technical sense and common sense. But URNs are not like that, because “ietf” and “rfc” are not path containers (e.g., directories); they are more like prefixes that disambiguate the last part (3986) to make the last part more universal. In fact there is no semantic difference between urn:ietf:rfc:3986, and urn:ietf-rfc:3986; one could register the ietf-rfc namespace identifier with no loss of URN namespace uniqueness or persistence guarantees.

The point of the : style is that it doesn’t participate in / path segregation.

Sean

---

From: Keith Moore <[email-masked]>
Date: Mon, 03 Nov 2014 10:14:53 -0500

> That is why it looks like urn:ietf:rfc:3986 and not urn:/ietf/rfc/3986.
Having hosted the Knoxville meeting where we first got some agreement on 
the syntax, I don't recall that being part of the discussion.    But the 
intent was certainly that URNs wouldn't look like URLs, other than 
having a similar prefix and not using any of the characters not allowed 
for URLs.

If using "/" in a URN makes people more likely to think that URNs make 
sense with relative URIs, then by a similar argument using "?" makes 
people more likely to think that queries can be applied to the resources 
named by URNs, and using "#" makes people more likely to assume that 
HTML-style fragments make sense with URNs.

In the past I've argued fairly vigorously that if "?" and "#" are 
applied to URNs that they should have very similar meanings as when they 
are used with URLs - namely that "?" be used for queries submitted to 
the resource itself (and not, say, to the resolution service), and "#" 
should be used to identify fragments determined by the content of the 
resource, as they are in HTML.   But if we extend the same logic to "/" 
and relative URIs then we paint ourselves into a corner where it's not 
possible to have any modifiers for URNs at all.  So maybe you and I both 
should reconsider our positions on the meanings of these characters as 
applied to URNs?

Keith

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 3 Nov 2014 11:50:50 -0500

> From: Sean Leonard <[email-masked]>

> NOT include slash / characters.

Or we can look at this as a design rule:  If relative references have
a defined meaning, use "/" to separate the relevant substrings.  If
relative references do not have a defined meaning, forbid "/".

Dale

---

From: Sean Leonard <[email-masked]>
Date: Mon, 3 Nov 2014 13:14:02 -0800

On Nov 3, 2014, at 7:14 AM, Keith Moore <[email-masked]> wrote:

> Having hosted the Knoxville meeting where we first got some agreement on the syntax, I don't recall that being part of the discussion.    But the intent was certainly that URNs wouldn't look like URLs, other than having a similar prefix and not using any of the characters not allowed for URLs.
> 
> If using "/" in a URN makes people more likely to think that URNs make sense with relative URIs, then by a similar argument using "?" makes people more likely to think that queries can be applied to the resources named by URNs, and using "#" makes people more likely to assume that HTML-style fragments make sense with URNs.

> relative references do not have a defined meaning, forbid "/".

Since I wasn’t at the Knoxville meeting, perhaps a fresh pair of eyes (plus just someone new, relatively speaking, to the discussion) can bring a new perspective. Yes, it appears to be a design rule, or at least a design principle.

It would have made sense for the data: URL to use base64url encoding rather than basic base64 encoding, but the interactions between relative references and RFC 3986 weren’t fully appreciated at that time. In RFC 3986 parlance, a non-empty hierarchical path can be:
 authority path-abempty
 path-absolute
 path-rootless

In the first two cases, the path starts with / . In the last case, / can appear but not at the start. I’m not sure if it was by design or accident, but urn:NID:NSS puts URNs in the class of path-rootless. It sort of follows that for URI schemes where you don’t want hierarchical path processing (syntactically, or semantically), at a minimum you wouldn’t want / at the beginning. Ideally, you wouldn’t use / at all.

It seems logical to me that if an absolute URI has a path part that starts with / , then it is designed to be used with relative path processing. If it does not start with / , then that is an implicit design signal that relative path processing would be relatively [lol] useless. Widely used URI schemes that do not participate in path segmentation include: mailto, news, cid, geo, tel. 

Back to URNs:
A lot of URNs seem to divide the namespace with colons : . This seems reasonable. A better and more consistent approach to URN construction is inductive. Consider a name, and make it universally unique by prefixing the name with colon-separated namespace dividers. Thus:

3986
rfc:3986
ietf:rfc:3986
urn:ietf:rfc:3986

Sean

---

From: Keith Moore <[email-masked]>
Date: Mon, 03 Nov 2014 16:38:29 -0500

> Since I wasn’t at the Knoxville meeting, perhaps a fresh pair of eyes (plus just someone new, relatively speaking, to the discussion) can bring a new perspective. Yes, it appears to be a design rul…

I disagree.  To me it looks like you're trying to retroactively impose 
design requirements on URNs that were never there in the first place, 
and where the need for them is dubious.   URNs are not URLs; they have 
different syntaxes because they serve different purposes and therefore 
have different requirements.   We would of course like to avoid 
confusion of various kinds between the two, and would like to minimize 
the potential for anomalous behavior when either users or 
implementations treat URNs as if they are URLs. But fundamentally, to 
the extent that users or implementors do that, those are errors on their 
part.  It's not a design principle that URNs should have to act just 
like URNs; it's actually contrary to their design.

> It would have made sense for the data: URL to use base64url encoding rather than basic base64 encoding, but the interactions between relative references and RFC 3986 weren’t fully appreciated at that time.

That's irrelevant.  The data: URL is not a URN.

>   In RFC 3986 parlance, a non-empty hierarchical path can be:
>   authority path-abempty
>   path-absolute
>   path-rootless

URNs do not have paths.

> Back to URNs:
> A lot of URNs seem to divide the namespace with colons : . This seems reasonable. A better and more consistent approach to URN construction is inductive. Consider a name, and make it universally unique by prefixing the name with colon-separated namespace dividers.
Again, URNs do not have paths or any other kind of hierarchy within a 
namespace.   How any NID assigns URNs that start with its prefix is its 
own business.   But trying to impose hierarchy within a URN namespace is 
harmful to URN persistence.   The namespace specific portion of a URN 
should be considered opaque.

Keith

---

From: Larry Masinter <[email-masked]>
Date: Wed, 5 Nov 2014 00:08:19 +0000

> > Sorry, that's just insane.  It makes no technical sense whatsoever.

It made good technical sense to support scheme-independent relative resolution.
Perhaps you disagree with prioritizing simplicity over power, but it's hardly grounds for calling the design "insane".

Larry

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 Nov 2014 20:27:22 -0500

> Perhaps you disagree with prioritizing simplicity over power, but it's hardly grounds for calling the design "insane".
I'm all for scheme independence.  Heck, I'm the one arguing that 
interpretation of URN modifiers must be scheme-independent.

But I've never seen how relative resolution of URNs (for any scheme) 
made any sense.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 Nov 2014 20:31:46 -0500

On 11/04/2014 08:27 PM, Keith Moore wrote:
>> Perhaps you disagree with prioritizing simplicity over power, but 
>> it's hardly grounds for calling the design "insane".

Ah, now that I've written the above, I see I should have said 
"namespace" rather than scheme.

URNs are fundamentally different creatures than (most) URLs. Because 
we'd like to be able to use both kinds of names in many of the same 
contexts, it's handy if the two can be handled in a similar fashion.   
And I've argued in the past that "#" and "?" for URNs should be handled 
exactly like they are for the most common URLs - by being interpreted in 
the context of the resources themselves.

But it really does seem that trying to shoehorn URNs into URL syntax and 
conventions for interpretation in every case just ends up being too much 
of a constraint, and the desire to make one syntax do too many different 
things threatens to make URN interpretation namespace-dependent, which 
is even worse than scheme-dependence.

Keith

---

From: Sean Leonard <[email-masked]>
Date: Wed, 5 Nov 2014 05:42:56 -0800

On Nov 4, 2014, at 5:31 PM, Keith Moore <[email-masked]> wrote:

>> I'm all for scheme independence.  Heck, I'm the one arguing that interpretation of URN modifiers must be scheme-independent.
>> 
>> But I've never seen how relative resolution of URNs (for any scheme) made any sense.
> 
> Ah, now that I've written the above, I see I should have said "namespace" rather than scheme.
> 
> URNs are fundamentally different creatures than (most) URLs. Because we'd like to be able to use both kinds of names in many of the same contexts, it's handy if the two can be handled in a similar fashion.   And I've argued in the past that "#" and "?" for URNs should be handled exactly like they are for the most common URLs - by being interpreted in the context of the resources themselves.
> 
> But it really does seem that trying to shoehorn URNs into URL syntax and conventions for interpretation in every case just ends up being too much of a constraint,

I agree with these literal statements.

However, I want to point out that these statements are comparing URNs and *URLs*. A URL (to the extent that still exists—I think it does exist) is a locator for a network-accessible resource. URNs are not locators, since they do not contain network address information, as network address information is not durable, persistent, unique, or registrable.

There are URIs that are not URLs. Behaviorally, these URIs illustrate similar behaviors and features to URNs. Examples:

news:example.group.this
tel:+1-201-555-0123
mailto:[email-masked]?subject=A%20Test

Some of these URIs (e.g., mailto) embed network resource identifiers (e.g., domain names), but they aren’t network addresses—they are basically launch commands to do local things.

As I see it, the main difference between these types of URIs and URNs is that URN namespaces undertake specific obligations for durability, persistence, uniqueness, and registrability.

Thus, urn:cid:[email-masked] is inappropriate because it may not be unique; no standard requires that the Content-ID be universally unique (and if the domain name is reassigned, there is no guarantee that the old and new registrants will coordinate this).

URNs are not URLs. But they are still identifiers—they just have specific properties. Saying that URNs are not URIs overstates the case.

Sean

PS Relative resolution for the URIs above (news, cid, tel, mailto) also does not make sense. I agree with Larry that scheme-independent relative resolution still has technical value. It is useful for a broad range of URIs, just not for all of them. Maybe it would be a good idea for new URI scheme registrations to state whether relative resolution has practical value. (The *mechanism* for relative resolution remains scheme-independent—an URI scheme shouldn’t invent a new kind of reference parsing algorithm, such as one that runs on . or : instead of / .)

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Nov 2014 14:57:21 +0100

> I agree with these literal statements.

(I don't)

> However, I want to point out that these statements are comparing URNs and *URLs*. A URL (to the extent that still exists—I think it does exist) is a locator for a network-accessible resource. URNs…

"network address information is not durable, persistent, unique, or 
registrable"

Hmm, no. It's just a different kind of registry with properties 
different from the URN registration process.

> URNs are not URLs. But they are still identifiers—they just have specific properties. Saying that URNs are not URIs overstates the case.

+1 on that.

Furthermore, I keep hearing of people who want to make URNs 
network-resolvable, in which case they become URLs as well, no?

> PS Relative resolution for the URIs above (news, cid, tel, mailto) also does not make sense. I agree with Larry that scheme-independent relative resolution still has technical value. It is useful f…

+1 on that too.

Optimally, the URI registration process document would point out that 
relative resolution is going to yield surprising results if you don't 
stick to the hierarchical model (and that registrants should make a 
conscious decision about that when defining a new scheme).

And, surprise 
(<http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-03#section-3.2>);

>    New schemes SHOULD reuse the common URI components of [RFC3986] for
>    the definition of hierarchical naming schemes.  If there is a strong
>    reason for a scheme not to use the hierarchical syntax, then the new
>    scheme definition SHOULD follow the syntax of previously registered
>    schemes.
>
>    Schemes that are not intended for use with relative URIs SHOULD avoid
>    use of the forward slash "/" character, which is used for
>    hierarchical delimiters, and the complete path segments "." and ".."
>    (dot-segments).

Best regards, Julian

---

From: Sean Leonard <[email-masked]>
Date: Wed, 5 Nov 2014 06:16:09 -0800

Keith, I think we are on the same page here—we are just using differing terminology.

On Nov 3, 2014, at 1:38 PM, Keith Moore <[email-masked]> wrote:

> I disagree.  To me it looks like you're trying to retroactively impose design requirements on URNs that were never there in the first place, and where the need for them is dubious.   URNs are not URLs; they have different syntaxes because they serve different purposes and therefore have different requirements.   We would of course like to avoid confusion of various kinds between the two, and would like to minimize the potential for anomalous behavior when either users or implementations treat URNs as if they are URLs. But fundamentally, to the extent that users or implementors do that, those are errors on their part.  It's not a design principle that URNs should have to act just like URNs; it's actually contrary to their design.

Ok—did you mean something else though by “It’s not a design principle that URNs should have to act just like URNs”? URNs are URNs…are you contrasting URNs with URLs?

>>  In RFC 3986 parlance, a non-empty hierarchical path can be:

I *think* we are in agreement.

URNs do not have paths.

But according to RFC 3986, the “NID:NSS” part is part of the path-rootless production, for urn: URIs. Thus when analyzed with the RFC 3986 URI generic syntax, NID:NSS are what some folks are now calling the “p-component”. I was just pointing out some mechanics.

> Again, URNs do not have paths or any other kind of hierarchy within a namespace.   How any NID assigns URNs that start with its prefix is its own business.  
> But trying to impose hierarchy within a URN namespace is harmful to URN persistence.

I was very careful in choosing the terms “prefix” and “namespace dividers”, rather than hierarchy. I was not proposing hierarchy in the RFC 3986 sense of a “hier-part”.

The purpose was to point out that punctuation serves to *divide* the namespace. The punctuation need not be a colon : ; it can be a period . or an at symbol @ .

For example:
urn:oid:2.5.4.3
 (which is for commonName)

is materially different from:
urn:oid:2.54.3
urn:oid:2.543

Punctuation matters. Punctuation serves to divide the namespace.

Semantically, a colon could have been used instead:
urn:oid:2:5:4:3

To Keith's point, the choice of punctuation is the namespace’s business. From a generic URN (or URI) parser’s perspective, fine, maybe they are opaque.

But the punctuation serves a common purpose to divide the arbitrary sequence of characters into discrete parts. A URN parser that is going to interpret OIDs for OID purposes needs to know how to divide the “opaque” string into numeric sequences, using “.” (not “:”) as the divider.

Compare this with urn:isbn. ISBNs can be 10 or 13 digits. RFC 3187 suggests that urn:isbn use - to separate certain number groups, such as:

urn:isbn:0-395-36341-1

But unlike . in OIDs, - in ISBNs do not affect lexical equivalence. (See Section 3.2 of RFC 3187.) Thus:
urn:isbn:0395363411

is lexically equivalent.

Furthermore, urn:isbn resolution may depend on digit sequences that are not neatly divided by - characters. This is straight from RFC 3187:
   For instance, "951-0" is the
   unique ISBN publisher identifier of the largest publisher in Finland,
   Sanoma-WSOY.  If they launch their own URN resolution services,
   resolution requests for ISBNs starting with "951-0" will be directed
   to the publisher's server, and all other requests to the national
   bibliography.

Anyway, since URN namespaces always include at least one colon, it is not surprising that the colon is used when the local identifier (name) does not have a preference for particular punctuation characters.

For example:

urn:ietf:rfc:3986
urn:iet:frfc:3986
urn:ietf:rfc3:986

are not the same.

-Sean

---

From: Keith Moore <[email-masked]>
Date: Wed, 05 Nov 2014 09:29:04 -0500

On 11/05/2014 09:16 AM, Sean Leonard wrote:
> Ok—did you mean something else though by “It’s not a design principle 
> that URNs should have to act just like URNs”? URNs are URNs…are you 
> contrasting URNs with URLs?

I meant "It's not a design principle that URNs should have to act just 
like URLs".

> But according to RFC 3986, the “NID:NSS” part is part of the path-rootless production, for urn: URIs. Thus when analyzed with the RFC 3986 URI generic syntax, NID:NSS are what some folks are now ca…

The chair has forbidden me to speak the truth about that RFC. However, I 
refuse to participate in telling lies about it.   So IMO it's better to 
not mention it at all in connection with URNs.

> Punctuation matters. Punctuation serves to divide the namespace.

Punctuation within the namespace specific string has no special meaning 
and should be treated just as if it were any other character, unless the 
thing doing the processing happens to know the specific rules for 
assigning names within that namespace.   But the whole point of URNs is 
to permit uniform handling of different kinds of URNs.   So things that 
process URNs in general shouldn't be trying to infer meaning from 
portions of the namespace specific string.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 05 Nov 2014 09:37:26 -0500

> different from the URN registration process.

Network address information is not durable, persistent, or unique. IP 
address blocks can be reassigned and will necessarily change over time; 
DNS registrations can be taken away or reassigned without consent of the 
party that assigned names based on them.

> network-resolvable, in which case they become URLs as well, no?

No, because names are not inherently locators.  That, and URN resolution 
doesn't depend on namespaces like DNS names or IP addresses that have 
inherently ephemeral associations with reality, and care has been taken 
to make sure that URN namespaces will only be delegated to parties that 
value persistence and will assign and maintain namespace-specific 
identifiers with due care.

>
>> Sean
>>
>> PS Relative resolution for the URIs above (news, cid, tel, mailto) 
>> also does not make sense. I agree with Larry that scheme-independent 
>> relative resolution still has technical value. It is useful for a 
>> broad range of URIs, just not for all of them. Maybe it would be a 
>> good idea for new URI scheme registrations to state whether relative 
>> resolution has practical value. (The *mechanism* for relative 
>> resolution remains scheme-independent—an URI scheme shouldn’t invent 
>> a new kind of reference parsing algorithm, such as one that runs on . 
>> or : instead of / .)
>
> +1 on that too.

Except that insisting that URNs behave exactly like every other URI, 
while it might seem good in isolation, ends up forcing different 
behavior for use of modifiers among different URN namespaces.    The 
problem is that the rules for URIs were really designed for hierarchical 
URLs and are too constraining.

>>    hierarchical delimiters, and the complete path segments "." and ".."

urn: is not a new URI scheme.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Nov 2014 15:52:54 +0100

> party that assigned names based on them.

The authority part of a URI doesn't even need to use IP adresses or DNS.

> ...
> ...

I didn't claim it was. I was just citing the draft because it has good 
advice here, and maybe it should affect what *this* WG defines for new NIDs.

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Wed, 05 Nov 2014 10:59:17 -0500

> The authority part of a URI doesn't even need to use IP adresses or DNS.

True enough.  I never said that people can't create other URIs that have 
similar properties to URNs.

> advice here, and maybe it should affect what *this* WG defines for new 
NIDs aren't URI schemes.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Nov 2014 17:09:30 +0100

>> advice here, and maybe it should affect what *this* WG defines for new

I known that, and you know that I do.

May point being: if there was consensus that the advice in the URI 
scheme registration draft is good then it would make a lot of sense to 
think about whether we can draw some conclusions for registrations of 
new NIDs.

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Wed, 05 Nov 2014 11:17:49 -0500

> think about whether we can draw some conclusions for registrations of 

Disagree, because they were considering a completely different case.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Nov 2014 17:21:49 +0100

> Disagree, because they were considering a completely different case.

I understand the use case as defining identifiers that will work in a 
predictable way when used as base URI for relative reference resolution.

Do you disagree that this is the use case?

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Wed, 05 Nov 2014 11:23:55 -0500

> Do you disagree that this is the use case?

I do.  URNs should never be used as base URIs for relative reference 
resolution.

Keith

---

From: Juha Hakala <[email-masked]>
Date: Thu, 06 Nov 2014 15:51:27 +0200

Hello Julian; all,

On 30.10.2014 22:36, Julian Reschke wrote:

>
> It would be helpful if there was more than hand-waving; a *concrete* 
> list of things you think are broken, please.

I don't mind the "small stuff" in RFC 3986 too much. What matters is 
that when the principles of the URI Generic syntax are applied for 
identification of things, we should always get identifiers which are 
persistent and unique and that it is always clear exactly what is being 
identified. It would also be nice if traditional identifier systems were 
accommodated and the process of identifier assignment were a properly 
managed process (whatever that means).

Since the proof is in the pudding, let's take a look at the results we 
get with RFC 3986. I concentrate on identification of names, and start 
with mailto:.

What does URI mailto:[email-masked] identify? There are a few 
options:

1. Person (Julian Reschke);
2. Public identity of a person who chooses to call himself Julian 
Reschke in public;
3. Mail box of 1);
4. All of 1-3, or 1-2, 2-3 or 1 and 3; or
5. Nothing.

Julian, what is your own take on this?

If we select 1-2 or 4 we need to consider if the mailto: identifier of  
a person is unique. Alas, it is not - a person may have several email 
addresses (I have three, for instance), and over time an email address 
may "belong" to different people. So mailto: identifiers are neither 
persistent nor unique and therefore should not be regarded as proper 
identifiers.

Cool URI proponents may say that although mailto:[email-masked] 
is a URI, it should not be used as a cool URIs. That may be the case, 
but then the set of all URIs would be divided into identifiers and 
non-identifiers in a way which is not explained properly in RFC 3986 or 
supporting documentation like W3C document Cool URIs for the semantic 
Web (http://www.w3.org/TR/cooluris/). If such division is formalized, 
IMO IETF takes a step back towards the old URL - URN approach in which 
it was always clear whether a string was a name or just a locator.

The Cool URIs for the semantic Web -document recommends two different 
approaches for identification of people. The key thing is to avoid 
confusing the person to his/her homepage. The resulting identifiers may 
look like this:

http://www.example.com/about#alice

or this:

http://www.example.com/id/alice

so careful design of the Web site is essential. Example (one that still 
works) of this approach from the W3C document:

> http://id.ecs.soton.ac.uk/person/1650
>     URI for Wendy Hall, the person
> http://www.ecs.soton.ac.uk/people/wh
>     HTML page about Wendy Hall
> http://rdf.ecs.soton.ac.uk/person/1650
>     RDF about Wendy Hall
>

There is another example providing two cool URIs for Chris Bizer, but 
unfortunately these URIs have already become un-cool because redirect 
from his previous to newer alma mater does not work  any more. Copies of 
the original Web pages can be found from the Internet Archive so the 
links in the W3C document can be fixed if there is a need to do so. I 
think there is; if even cool URIs in W3C guidelines documents die in a 
few years time it undermines the faith in coolness of URIs in general.

I don't want to discuss here whether an URI like 
http://id.ecs.soton.ac.uk/person/1650 is a good (read: unique and 
persistent) identifier for a person. But IMO it is a problem that Dame 
professor Wendy Hall has already two standard identifiers and one de 
facto identifier, all of which could be used as URIs:

http://orcid.org/0000-0003-1634-6930#sthash.Uxnc5LLd.dpu
ResearcherID A-6432-2009
ORCID 0000-0003-1634-6930 (https://orcid.org/0000-0003-1634-6930)
ISNI 0000 0000 8405 0259

As an aside, metadata record in the ISNI database is a result of merger 
between two professor Wendy Halls, one a (famous) computer scientist, 
another a specialist in obstetrics. No system is perfect!

 From my community's point of view, it is definitely a problem that W3C 
recommended identifier approach ignores existing identifiers for public 
identities (and persons), and introduces yet another identifier system 
which encompasses personal names and basically everything else that the 
Web can cover one way or another. This kind of parallel identifier 
system may create a lot of confusion if applied carelessly.

IMO the likelihood of a poor implementation of the W3C approach is high, 
since cool URIs are usually managed at grass roots level. Such approach 
does not foster persistence, and indeed the short lifetime of links and 
reference rot are major problems to the semantic Web.

Since there are no strict rules for cool URI assignment, it is not clear 
why one URI is better than another and how to choose the one URI from 
among the many possible ones. From persistence and exhaustiveness points 
of view, a work related Southampton university URI is not likely to be a 
better identifier for Wendy Hall than e.g.

http://en.wikipedia.org/wiki/Wendy_Hall

since the Wikipedia URI will be more persistent than anything personal 
or work related. And of course the archived version of Wikipedia page, 
available at:

https://web.archive.org/web/*/http://en.wikipedia.org/wiki/Wendy_Hall

is in turn likely to be more persistent than any URL in the living Web, 
including Wikipedia pages.
http://orcid.org/0000-0003-1634-6930#sthash.Uxnc5LLd.dpuf

How would information sciences community give URIs to names? One 
possibility is to use URI based on ORCID (or ISNI) to retrieve a 
metadata record which provides links to relevant web pages, such as 
Wendy Hall's Wikipedia page, work / private home pages and so on. In 
this model the identifier would be unique and persistent, and it is 
crystal clear what has been identified (since that has been specified in 
ISNI / ORCID standards and community guidelines).

URN fosters the use of existing standard identifiers such as ISNI and 
ORCID. This is one reason why the information sciences community prefers 
them over the current, rather loosely managed embodiment of cool URIs.

One more thing: I am not requesting any changes to the RFC 3986 and 
related W3C documents. Things will or will not change based on the 
practical experiences of semantic web implementers and users. If it 
ain't broke, don't fix it - if cool URIs eventually become cool enough, 
they may be a sufficient solution for at least some Web user  communities.

All the best,

Juha
>
>
> Best regards, Julian
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678

---

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Nov 2014 15:13:00 +0100

> Julian, what is your own take on this?

My take on this is that you're now fully in "resource semantics" mode; 
something very smart people have been discussing since we have URIs 
(it's BTW the reason why the W3C TAG was established).

I don't plan to participate in that discussion; can we concentrate on 
the syntax and the operations defined by RFC 3986?

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Thu, 06 Nov 2014 09:47:49 -0500

> the syntax and the operations defined by RFC 3986? 

Can we concentrate instead on the syntax for URNs, since that's the 
topic of this group, and we've been forbidden to talk about what's wrong 
with RFC 3986?

Keith

---

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Nov 2014 15:56:17 +0100

> topic of this group, and we've been forbidden to talk about what's wrong

That's what should be discussed here, right.

Keith: if you want to follow up on that other topic, I recommend using 
the URI mailing list (<[email-masked]>).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 06 Nov 2014 15:03:56 +0100

Best regards, Julian

---

From: Sean Leonard <[email-masked]>
Date: Sun, 9 Nov 2014 16:12:34 -1000

On Nov 6, 2014, at 3:51 AM, Juha Hakala <[email-masked]> wrote:

> 
> What does URI mailto:[email-masked] identify? There are a few options: 

mailto: may not be the best example. Yes, it is an identifier…but it really is meant to be a launch code for composing an e-mail in an e-mail client.

RFC 6068 says:
   The 'mailto' URI scheme is used to identify resources that are
   reached using Internet mail.  In its simplest form, a 'mailto' URI
   contains an Internet mail address.  […]

   A 'mailto' URI designates an "Internet resource", which is the
   mailbox specified in the address.  When additional header fields are
   supplied, the resource designated is the same address but with an
   additional profile for accessing the resource.  While there are
   Internet resources that can only be accessed via electronic mail, the
   'mailto' URI is not intended as a way of retrieving such objects
   automatically.

   The operation of how any URI scheme is resolved is not mandated by
   the URI specifications.  […]
   The 'mailto' URI has unusual semantics because resolving such a URI
   does not cause an immediate interaction with a server.  Instead, the
   client creates a message to the designated address with the various
   header fields set as default.  The user can edit the message, send
   the message unedited, or choose not to send the message.

RFC 2368 says more-or-less the same thing.

If you want to designate a way to access a mailbox, you use imap: or pop: URIs.

If you want to designate an e-mail address, just the e-mail address <[email-masked]> will do the trick.

If you want to cause an URI processing software system to launch e-mail software to send e-mail to an e-mail address, you use mailto:. And you can specify headers and such.

I guess the point is that mailto: doesn’t really identify anything—at least not your 1, 2, 3, or 4. It *consumes* identifiers as part of its function to send e-mail. Arguably, it identifies a not-yet-created e-mail message with some fields filled in. By analogy, http://example.com/foo doesn’t identify a domain name, or a path. It consumes those identifiers as part of its function to do something else (in this case, actually identify a complete resource accessible over HTTP, as well as cause the resource to be retrieved, when the URI is dereferenced).

Perhaps this helps to clarify the distinction between what a URN identifies, what a URN does when resolved, and what identifiers a URN consumes as part of its function?

Sean

---

From: Juha Hakala <[email-masked]>
Date: Mon, 10 Nov 2014 15:34:23 +0200

Hello,

On 10.11.2014 4:12, Sean Leonard wrote:
> On Nov 6, 2014, at 3:51 AM, Juha Hakala <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>
> mailto: may not be the best example. Yes, it is an identifier…but it 
> really is meant to be a launch code for composing an e-mail in an 
> e-mail client.

I used mailto: as an example since its role in identification is 
discussed in the WWW architecture document 
(http://www.w3.org/TR/webarch/#identification):

> To say that the URI "mailto:[email-masked]" identifies both an 
> Internet mailbox and Nadia, the person, introduces a URI collision. 
> However, we can use the URI to indirectly identify Nadia. Identifiers 
> are commonly used in this way.
>
> Suppose that [email-masked]| is Nadia's email address. The 
> organizers of a conference Nadia attends might use 
> "mailto:[email-masked]" to refer indirectly to her (e.g., by using 
> the URI as a database key in their database of conference 
> participants). This does not introduce a URI collision.
>

I find it interesting that WWW architecture document uses a trivial 
example like this. The problems information sciences community (and, 
eventually, the Web too) must solve are more complicated. For instance, 
there are about 20.000 Dr. Wang's who are currently active researchers, 
and it is necessary to identify them all to give merit to whom it 
belongs, taking into account that 40 years from now there will be 10.000 
new Dr. Wang's. This cannot be done by using email addresses or personal 
home pages as identifiers. An email address can have a supporting role 
(it is used in such way in ORCID system) but it should not be used as an 
identifier, indirect or otherwise.

> (it's BTW the reason why the W3C TAG was established).

URNBIS avoids the semantics problem since in the URN system resource 
semantics (for instance: what can be identified, and how) is specified 
separately in each namespace in documents like the ISBN manual (which 
settles things for urn:isbn). To put this in other words, URNBIS has no 
mandate to say that according to this or that URI principle the current 
practice of ISBN assignment is wrong and has to be modified if ISBNs are 
to be used as URNs.

Indeed, W3C TAG has spent a lot of time trying to deal with resource 
semantics in the Web/URI context, but based on

http://www.w3.org/2001/tag/group/track/issues/

it seems that there is still a lot of work to be done (persistence of 
identifiers -task is still open, nine years after it was established).  
And given the magnitude of the problem in the URI context I don't 
believe there will ever be a solution that would make all the Web users 
happy.

> the syntax and the operations defined by RFC 3986? 

Unfortunately URNBIS gets into trouble when conclusions regarding the 
URI/URN syntax are drawn from the URI semantics. For instance, the URL 
of somebody's homepage could "identify" both the person and the 
homepage. So there is a recommendation that the home page URL is used to 
identify the home page, and the home page URL + fragment is used to 
identify the person.  To give a fragment a role like this is OK from the 
RFC 3986 point of view, but not acceptable for most standard identifiers 
which do not allow adding URI fragments to NSS. (And the information 
sciences community certainly does not and will not identify people with 
their home page URLs, with or without fragments.) The latest RFC 2141bis 
solves this problem (and other syntax issues I am aware of) in a way 
which works for me.

Sean; concerning this:

>
> I guess the point is that mailto: doesn’t really identify anything—at 
> least not your 1, 2, 3, or 4. It *consumes* identifiers as part of its 
> function to send e-mail. Arguably, it identifies a not-yet-created 
> e-mail message with some fields filled in. By analogy, 
> http://example.com/foo doesn’t identify a domain name, or a path. It 
> consumes those identifiers as part of its function to do something 
> else (in this case, actually identify a complete resource accessible 
> over HTTP, as well as cause the resource to be retrieved, when the URI 
> is dereferenced).

IMO sensible people can and will have different views on what mailto: 
identifies (if anything). It is unlikely that any resource semantics 
guidelines in Web architecture documents will fully eliminate this 
problem. On the other hand, there is a simple solution for this problem 
in the URN system: do not approve mailto: namespace, since a) email 
addresses are neither unique nor persistent, and b) it is not obvious 
what they identify.

Juha

>
> Perhaps this helps to clarify the distinction between what a URN 
> identifies, what a URN does when resolved, and what identifiers a URN 
> consumes as part of its function?
>
> Sean
>
>
>

-- 

  Juha Hakala
  Senior advisor

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Nov 2014 17:56:52 -0500

On 11/09/2014 09:12 PM, Sean Leonard wrote:
> I guess the point is that mailto: doesn’t really identify anything

Well, you can use it as a way to identify something.    Just because the 
historical behavior associated with mailto: in a browser is to launch an 
email compose window when clicked, doesn't mean that's what mailto: means.

But I don't see what any of this has to do with URNs, because mailto: 
URIs aren't URNs.

Keith