Subject: [urn] URNs, URIs, this working group's job, and some steering

From: Barry Leiba <[email-masked]>
Date: Wed, 9 Jul 2014 16:32:42 -0400

Hey, all.
I'd like to throw in an AD interrupt designed to steer the recent
discussion a bit.

What this working group needs to do is update the various URN specs,
specifically taking into account the needs of the library community --
as we update the specs for ISBN and the others.

We determined that we were getting stuck in some of the discussions by
a disparity in the needs we were considering and the restrictions that
RFC 3986 puts on URNs.  Of course, there's an issue here: the URN
specs all predate 3986, and 3986 said things about URNs with a
different view and different needs in mind.

John has proposed one way of dealing with this issue and allowing us
to make the kinds of changes we need to make.  As we discuss John's
proposal we have to keep in mind what this working group's goal is,
and work toward it.

That means that it's valid to say that John's proposal isn't the right
or best way, but that has to go with a technical discussion of an
alternative proposal that can achieve our goals.  We're at a point, I
think, where we have to move ourselves out of what I call the "Grand
Unified Theory of URIs", and think about the specific needs for URNs
among a growing set of disparate communities that use them (I've
processed at least seven documents dealing with URN namespaces in my
2.5 years as AD, so "growing" is quite accurate).  If we hold on to an
ideal that doesn't serve the needs of the users, no one wins.

So let's please make sure that as we argue against anything that's
proposed, we have an alternative proposal that keeps us moving in the
right direction.

Barry, Applications AD

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Jul 2014 09:01:41 +0200

On 2014-07-09 22:32, Barry Leiba wrote:
> ...

I believe what's needed is a *concise* explanation about what particular 
bits in RFC 3986 are considered a problem. Do we have that? (Pointers 
sufficient).

Best regards, Julian

---

From: Juha Hakala <[email-masked]>
Date: Thu, 10 Jul 2014 13:39:06 +0300

Hello,

On 10.7.2014 10:01, Julian Reschke wrote:
> I believe what's needed is a *concise* explanation about what 
> particular bits in RFC 3986 are considered a problem. Do we have that? 
> (Pointers sufficient).

This issue has been discussed several times, but once more the main 
issues memory institutions have with the RFC 3986:

1. The general idea that every URI is an identifier,  and the very loose 
specification of "identifier" built in into such a statement which does 
not match with the meaning the term identifier has in the URN context.

Does [email-masked] identify me or my mail box or both? And if 
we agree that [email-masked] does identify me, is it good 
identifier in the URN sense of the word (unique and persistent)? To me 
my email address is neither unique (I have other email addresses) nor 
persistent (it won't work after I leave the university) and therefore it 
does not properly identify me, but it seems that those who endorse RFC 
3986 disagree, or just ignore some consequences of the basic assumptions 
made in RFC 3986.

2. Regarding query, chapter RFC 3986 says:

> The query component contains non-hierarchical data that, along with
>     data in the path component (Section 3.3), serves to identify a
>     resource within the scope of the URI's scheme and naming authority
>     (if any).

It is difficult to tell what "within the scope of the URI's scheme and 
naming authority" means. Or, what happens if there is no naming 
authority. Obviously not all URIs with query are identifiers after all.

And if query components do identify something, what would it be. For 
instance in this URI:

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&
query=dinosaur&maximumRecords=1&recordSchema=dc 
<http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dinosaur&maximumRecords=1&recordSchema=dc>

we might say that http://z39.50.loc.gov:7090 is an identifier of the 
Library of Congress OPAC. The SRU query changes the URI so that it 
becomes an identifier of a single record retrieved from that database. 
And that record would not remain the same; each time a new record with 
the word dinosaur in it is added to the database, it replaces the 
previous record.

OK, we can say that the quote from RFC 3986 above applies, and the URI 
in the example is not an identifier at all in spite of being URI. But 
without precise guidelines on how to apply "within the scope of the 
URI's scheme and naming authority" we are left with the situation where 
any URI with query component may or may not identify something.

In the URN context, NSS is stable and identifies the resource. Queries 
are attached to established URNs when necessary, depending on what 
resolution services the users want. But they do not have any role in 
identification, and they are not meant to be persistent since the 
technical infrastructure which provides services is changing. That is, a 
user may see a URN and tick a box saying "do you want metadata about 
this resource", and behind the screen the user interface app builds a 
valid query string and adds it to the URN.

3. RFC 3986 says the following about fragment in chapter 3.5:

> The fragment identifier component of a URI allows indirect
>     identification of a secondary resource by reference to a primary
>     resource and additional identifying information.  The identified
>     secondary resource may be some portion or subset of the primary
>     resource, some view on representations of the primary resource, or
>     some other resource defined or described by those representations.

Technically there is no problem here. The entire resource is always 
retrieved, and fragment is only applied by the client such as a Web 
browser. So fragments have a priori nothing to do with the URN resolution.

Typical use case is a researcher who cites a document, and adds a 
fragment to the URN so that readers who click the link are taken 
directly to the relevant location within the referred resource.

The problem is that if fragments are identifiers, then anyone can 
identify any bits and pieces within resource that has previously been 
identified by URNs. Such expansion of the scope of e.g. ISBN is not 
possible; readers can not assign identifiers to chapters of books as 
they wish. But the whole problem vanishes if fragment is not an 
identifier in the URN context.

Since RFC 3986 was published, people have invented all kinds of 
interesting usages for fragment. The more I know about them, the harder 
it is for me to see what fragments do identify. For instance, does this

|http://example.com/document.txt#match=[rR][fF][cC]
|
identify every "rfc" and "RFC" in the target document? Or does it just 
find them?

To sum up, probably the main challenge we are facing is that "to 
identify" means different things to different communities. Worse, 
identification in the URN context does not mean the same as it means in 
the URI context. In the latter, the meaning of the term has been 
expanded so that the communities which have a lot of experience about 
identification of resources such as libraries don't really agree with it 
anymore. URN definition of the term, on the other hand, is OK.

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, 10 Jul 2014 15:01:05 +0200

Hi Juha,

thanks for the feedback.

> not match with the meaning the term identifier has in the URN context.

So that's a terminology problem. I think it's totally OK if the URI 
scheme "urn" has stronger requirements on a specific term, as long as it 
doesn't contradict RFC 3986.

> 3986 disagree, or just ignore some consequences of the basic assumptions

Assuming you mean "mailto:...". It is an identifier of a mailbox (as per 
<http://tools.ietf.org/html/rfc6068#section-3>). Whether it is *your* 
mailbox (or even an in-use mailbox) can vary over time.

I understand that the URN community isn't interested in identifiers that 
do not offer stability for your use cases, but that's hardly a defect of 
3986. URNs are still URIs if you have a higher bar on identification. 
What would be a problem is the reverse case.

> authority. Obviously not all URIs with query are identifiers after all.

No, that's not only not obvious, it's wrong. Any *URI* by definition is 
an identifier.

I think this definition is pretty clear; do you have any specific 
proposed change that would make it work better for you?

> the word dinosaur in it is added to the database, it replaces the

Yes. That's a feature.

> in the example is not an identifier at all in spite of being URI. But

I don't see where RFC 3986 says that.

> any URI with query component may or may not identify something.

They all identify something.

The "scope of the URI's scheme and naming authority" is the hook where 
this WG, writing the spec for the "URN" scheme, and authors of NSS 
specs, can add additional semantics on top.

> valid query string and adds it to the URN.

That's not a problem as long as the spec for the "URN" scheme says so.

> identifier in the URN context.

RFC 3986 goes on saying:

"The semantics of a fragment identifier are defined by the set of 
representations that might result from a retrieval action on the primary 
resource. The fragment's format and resolution is therefore dependent on 
the media type [RFC2046] of a potentially retrieved representation, even 
though such a retrieval is only performed if the URI is dereferenced. If 
no such representation exists, then the semantics of the fragment are 
considered unknown and are effectively unconstrained. Fragment 
identifier semantics are independent of the URI scheme and thus cannot 
be redefined by scheme specifications."

So essentially the semantics depend on the format you get on retrieval, 
and if there is no such thing, it's unknown.

That sounds to me that unless you actually define a resolution service, 
you'd better not use fragments.

> identify every "rfc" and "RFC" in the target document? Or does it just

It depends on the media type and the fragment identifier semantics for 
that type.

> anymore. URN definition of the term, on the other hand, is OK.

So we need to split URNs out of the URI space because URN's requirements 
for the term "identify" are stronger than those in RFC 3986? Seriously?

After all, the spec for the "URN" scheme is free to redefine "identify" 
for URNs, as long as it's consistent with the looser definition in 3986.

Best regards, Julian

---

From: Larry Masinter <[email-masked]>
Date: Thu, 10 Jul 2014 16:56:39 +0000

+1 to Julian's comments, however:

Barry Leiba wrote:
> alternative proposal that can achieve our goals.

In that spirit, here is an outline of an alternative proposal which
I think would help URNbis to accomplish its goals, even if
not absolutely necessary.

I think that these updates to 3986 would be 
consistent with real URI use, and give the URNbis
working group more rope to make the changes wanted,
for those URN namespaces  used to identify 
location-independent static documents in
digital library contexts, but without stepping on 
other kinds of URNs and applications of them,
or appearing to disallow a urn in contexts that
currently allow a URI or an IRI.

========================
1. Integrate IRI so that the support for non-ASCII
    URNs are clearer.  

    URNbis doesn't like %-hex encoding for non-ASCII
    names, that's fine, but there's no need if urn
    is defined in terms of IRI.

    Could URNbis please (quickly) review
    http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg
    and see if it is sufficient to allow the "urn:" URI
     scheme to let naming authorities assign names
    with non-ASCII characters?

2. Clarify equivalence relationships, making it clear
    that schemes may define per-scheme equivalence
     relationships.

      This would more clearly allow URNbis to define
      an equivalence relationship for URNs which
      ignored query components for the purpose of
      library applications, while letting other applications
      and schemes use other equivalence relationships.
      http://tools.ietf.org/html/draft-ietf-iri-comparison-02
      was an attempt to do so, and could be brought
      forward. Please review.

3. Update # fragment meaning and let it be
     scheme dependent.

I think it would be helpful to update what RFC 3986
says about #-delimited "fragment identifiers":

a) point out that the "fragment identifier" is used
    to indicate "initial view" or "perspective" or 
    "script parameters", not just a "component".
b) let the interpretation of fragments be overridden
     by scheme and/or context of use, 
     with the current 'defined by the MIME type' 
     the default, applying unless otherwise specified
    to all URIs used for retrieval/fetch.
c)  Let the definition of fragments for URNs 
     be delegated to the namespace authority.

4. I would also promote other change in URNbis
to more clearly associate URNs with "managed
processes" rather than "permanent",
since permanence is more a matter of intention
of and for the namespace authority, and give
a better framework for talking about the use of
services that offer to 'resolve' a URN even when
the URN isn't defined as the result of a resolution
service (which most aren’t.)

This isn't absolutely necessary but it would
reduce much of the confusion about URNs
and their 'fundamental difference' from URIs.

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

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 10 Jul 2014 16:50:05 -0400

> From: Juha Hakala <[email-masked]>

> issues memory institutions have with the RFC 3986:

Many thanks for providing your summary!

> not match with the meaning the term identifier has in the URN context.

My understanding is that a URI is intended to "identify" some
"resource", in the broadest sense of both of the words in quotation
marks.  And I believe it to be understood that only the URIs that are
called URNs (which at the moment, are exactly the same set as the ones
whose scheme is "urn") have the sorts of properties that are
characteristic of what are (on this mailing list) called "names".

As far as I can tell, when you write "identifier" you are using much
the same concept as when most of the rest of us write "name".  In
particular, we do not expect mailto:, http:, or sip: URIs to behave in
ways that resemble "names", and we wouldn't expect a memory
institution to use them as such.

Or to turn that statement around, we expect memory institutions to be
interested in only a small subset of the universe of URIs, the ones
that are called URNs.  Which means that the problem is:  Does the set
of URNs (current and potential) suffice for the needs of memory
institutions?  The fact that other URIs are not suitable for memory
institutions is not important.

> anymore. URN definition of the term, on the other hand, is OK.

For proper memory use, confine your attention to URNs.  The other
parts of the URI space won't work for memory (and aren't even intended
to).

> And if query components do identify something, what would it be. For 

It seems to me that the key text is "within the scope of the URI's
scheme and naming authority", that is, the query part can only be
understood based on the definition of the scheme.

The only schemes that I know of that define the use of "query" are the
http:/https: and sip:/sips: schemes.  And indeed, the generic urn:
scheme syntax (RFC 2141) doesn't permit query components at all.  So
currently there is no defined meaning for query when used with names
(identifiers, as you call them) and they are not to be used.

An interesting question is whether amending RFC 2141 to permit query
components in URNs would be useful to solve any existing problem.  It
seems that there have been proposals for using query to specify what
particular sort of information is wanted about the named resource
(usually in the way of providing a "metadata" alternative), and for
specifying what (non-default) resolution service should be use for
locating the resource.  It seems to me that both of these could be
accommodated within the framework of RFC 3986 by amending RFC 2141.

> valid query string and adds it to the URN.

That would seem reasonable to me.  And that is one reason to have a
syntactically identifiable "query" part, or something like it:  It is
often convenient, when inserting a URI into an application, to be able
to attach information to it that indicates some sort of non-default
handling.  If the application handles the URI "opaquely", that is,
does not try to analyze the URI, the user can adjust the application's
behavior by changing the query part.  If the application wants to have
more control, there is a standardized way for it to detach the
"decoration" information from the more stable "identification"
information.

Of course, this is cheating on the definition of "name", but it is
very useful in practice.

For example, if we define the query part "metadata" to mean that one
desires to retrieve the metadata about a book, rather than the
contents of the book, then the name of the metadata is:

    urn:isbn:0-395-36341-1?metadata

Strictly speaking, it is only the definition of the urn: scheme that
would fix this use of the query part.  But it would be a convenient
convention, because it gives us a way to write a name for the
metadata.  In a philosophical way, we can consider the metadata to be
part of the resource that is the book <urn:isbn:0-395-36341-1>.  OTOH,
the "book" <urn:isbn:0-395-36341-1> is only a mental construction; it
designates a large set of nearly identical physical objects.

But very conveniently, a human or application can easily extract the
URN of the underlying "book" by deleting the query part to obtain:

    urn:isbn:0-395-36341-1

(This causes me to imagine a future retrieval device in a library,
which when presented with <urn:isbn:0-395-36341-1> delivers to the
user a *physical book*.  To obtain a digital representation,
<urn:isbn:0-395-36341-1?data> must be used ...)

Another example: a human could present this quasi-name to an
application:

    urn:isbn:0-395-36341-1?resolver=z3950.loc.gov

because the human knows that the resolver at z3950.loc.gov is "better"
in some way for this particular retrieval task.

But if the application saves the URN and now or later discovers that
the quasi-name is unusable because z3950.loc.gov no longer exists in
DNS, the application can *algorithmicly* remove the query to obtain

    urn:isbn:0-395-36341-1

which can be assumed to be more semantically stable than the above URN
(though it would have been less useful when the name was initially
used).

> directly to the relevant location within the referred resource.

I think everyone agrees with you on those points.

> identified by URNs.

I don't think I understand you here.  In most cases, the only fragment
identifiers that can be used with a particular URN are the ones that
are specifically defined within the body of the retrieved resource.
(Exactly how the body specifies fragment identifiers is determined by
the MIME media type of the body, but *not* the scheme of the URN.)
The only person who can designate an identified fragment is the person
who can alter the body of the resource to add a designation to it.

(There is an exception in RFC 5147, which defines fragment identifiers
for text/plain bodies.  It uses character and line positions as a
coordinate system for defining locations within the body.  So in the
case of text/plain bodies, anyone can identify any bit of the body
that they please, without coordination with the author of the body.)

> identify every "rfc" and "RFC" in the target document? Or does it just 

You can't tell without knowing the media type of the resource
accessible via http://example.com/document.txt.  My guess is that it
would have media type text/plain, in which case fragment identifiers
would be interpreted under RFC 5147, and 5147 does not provide for a
fragment identifier containing "match=".

In addition, there seem to me to be related issues involving:

- internationalization

URIs can only directly use a subset of US-ASCII, and URNs are thus
limited in the same way.  This is inconvenient for constructing URNs
that reference any natural language than English.  However, there is
an escape mechanism that allows any Unicode character to be expressed
in an awkward escaped way.  That leads to:

- user presentation

Currently, the standards define only how URNs appear "on the wire".
There is an assumption that whenever URNs have to be input by a user
or displayed to a user, they will be presented in a form very close to
the "wire" format.

However, the limited character set of URNs is largely based on the
desirability of embedding them in longer text strings, as that makes
it easier to parse the longer string and extract the URN.  "For
example, please click on <http://example.com/document.txt>."  However,
in may circumstances (e.g., GUIs), the URN string is "framed" in a way
that is not inconvenienced by any character that the string might
contain.

(A similar phenomenon happens in file names.  In Unix systems, file
names are very often written in a "command line" context where the
space character has a special meaning.  That requires a space that is
contained in a file name to be represented in an awkward "escaped"
format.  But in MS Windows systems, file names are almost always
presented in a GUI context where space has no special meaning.  Thus,
file name entry in Windows rarely needs to treat the space character
in a special way.)

In this regard, we may want to standardize two different ways of
presenting a URN:  one which adheres to the current syntax and is to
be used "on the wire", and one which allows direct expression of
arbitrary linguistic text, but which depends on external framing.  The
latter format could be used for user interaction in situations where
the interface provides framing.  We could then standardize a mapping
between the two formats.

Dale

---

From: Juha Hakala <[email-masked]>
Date: Fri, 11 Jul 2014 11:20:56 +0300

Hello Dale,

> Many thanks for providing your summary!

Thanks; just keep in mind that it is my personal take on the situation, 
not something that has been endorsed by libraries, archives, museums, 
scientific publishers, universities etc. which routinely apply 
persistent identifiers since they have good reasons to believe that 
plain vanilla URIs (URLs) will meet their requirements.

> characteristic of what are (on this mailing list) called "names".

Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and 
extensible naming system".

Section 1.1.3 of RFC 3986 says that:

> An individual scheme does not have to be classified as being just one
>     of "name" or "locator".  Instances of URIs from any given scheme may
>     have the characteristics of names or locators or both

This allows the use of e.g. HTTP URIs as names.
> institutions is not important.

It seems to me that the problem URNBIS has in its collective hands is a 
bit more complicated than that. This quote from Wikipedia URN page 
illustrates the situation:

> Defined in 1997 in RFC 
> <http://en.wikipedia.org/wiki/Request_for_Comments> 2141, URNs were 
> intended to serve as persistent 
> <http://en.wikipedia.org/wiki/Persistent_identifier>, 
> location-independent identifiers, allowing the simple mapping 
> <http://en.wikipedia.org/wiki/Map_%28higher-order_function%29> of 
> namespaces <http://en.wikipedia.org/wiki/Namespace> into a single URN 
> namespace.^[1] 
> <http://en.wikipedia.org/wiki/Uniform_resource_name#cite_note-FOOTNOTERFC_21411997-1> 
> The existence of such a URI does not imply availability of the 
> identified resource, but such URIs are required to remain globally 
> unique and persistent, even when the resource ceases to exist or 
> becomes unavailable.^[2] 
> <http://en.wikipedia.org/wiki/Uniform_resource_name#cite_note-FOOTNOTERFC_39862005-2> 
>
>
> Since RFC 3986^[2] 
> <http://en.wikipedia.org/wiki/Uniform_resource_name#cite_note-FOOTNOTERFC_39862005-2> 
> in 2005, the use of the term has been deprecated in favor of the 
> less-restrictive "URI", a view proposed by a joint working group 
> between the World Wide Web Consortium 
> <http://en.wikipedia.org/wiki/World_Wide_Web_Consortium> (W3C) and 
> Internet Engineering Task Force 
> <http://en.wikipedia.org/wiki/Internet_Engineering_Task_Force> 
> (IETF).^[3] 
> <http://en.wikipedia.org/wiki/Uniform_resource_name#cite_note-FOOTNOTEW3C.2FIETF2001-3> 
> Both URNs and uniform resource locators 
> <http://en.wikipedia.org/wiki/Uniform_resource_locator> (URLs) are 
> URIs, and a particular URI may be a name and a locator at the same time.
>

If both URNs and URLs can be names, the question is whether URNs are 
somehow superior compared with URLs as names. Mainstream thinking - also 
present in RFC 3986 - is that persistence of an URI is an administrative 
issue, and that both URLs and URNs can be administered well enough. The 
communities which prefer URNs and other persistent identifiers do not 
subscribe to this.

> parts of the URI space won't work for memory (and aren't even intended

Had we been able to concentrate on URN specifications only, we would 
have completed the new URN specifications long time ago. But there are 
things in URI syntax which "invade" the URN domain, starting from the 
general idea that the term URN can be deprecated in favour of URI, and 
that URLs are equally good as names as URNs.

> (identifiers, as you call them) and they are not to be used.

Alas, there is a need to use query for passing resolution related 
information to URN resolvers. We have no viable alternative for query 
usage, and other PID systems (ARK, Handle and DOI) are already using 
query for this purpose. We might still be able to align all these 
identifiers, and thus increase interoperability. On the other hand, it 
is almost certain that even if RFC2141bis would not allow query, URN 
community will start using query in the near future. Then there will be 
two variants of URN, plain vanilla IETF one and an enriched version used 
by those communities who are actually using URNs for identification 
purposes.

> Of course, this is cheating on the definition of "name", but it is

If we say that query is not part of the namespace specific string 
("name") there is no cheating involved.

This can be achieved by saying that in URN namespaces query does not 
identify a resource unless the naming authority registering that 
particular namespace says so in the registration request. RFC 3986 
enables this kind of interpretation:

>      urn:isbn:0-395-36341-1?metadata

Yes, this is a good example of how we want to use the query. However, in 
reality there are many different kinds of metadata, and it must be 
possible to specify what we want. Also, we need to be backwards 
compatible with RFC 2483. That's why I've used examples like

urn:isbn:0-395-36341-1?s=URC&p=DC

To me, this is not the name of the Dublin Core record of the book, but 
just a URI which is mapped by the URN resolver into e.g. a SRU search 
which is passed to the appropriate target.

> designates a large set of nearly identical physical objects.

Libraries, archives, museums etc. have well established practices on how 
they see their collections and objects in them. Existing identifiers and 
identifier assignment practices have evolved in this environment, and 
they are now being applied and adapted for digital collections.

For us, there are two kinds of mental constructions: works (such as Gone 
with the wind) and expressions (Finnish translation of Gone with the 
wind). Then there are physical manifestations (1st edition of Gone with 
the wind) and items (copies of the 1st edition of the Gone with the 
wind). Identifiers are used in all these levels, although for items they 
do not need to be globally unique.  Metadata (including these 
identifiers) enables the users to find and locate these materials.

> <urn:isbn:0-395-36341-1?data> must be used ...)

Digital manifestation of the book must have a different ISBN than the 
printed one. So if the default service is the retrieval of the resource, 
mere urn:isbn:<isbn> should do. But the user could use the identifier of 
the work to see all the available versions of the book, and pick the one 
- for instance a PDF instead of plain text version - that suits his 
requirements best.

> in some way for this particular retrieval task.

We do need to make URN resolvers smarter, and giving the users the 
possibility to select the server is something that needs to be 
considered. The easiest option for doing this is that the resolver is be 
aware of n different servers which can provide services for a given URN. 
For instance, for

urn:isbn:0-395-36341-1

appropriate targets include Finnish national union catalogue, OCLC's WorldCat and Google Scholar, to name just a few. A library application could consult the URN resolver about the targets available, and then allow the user to select between them, or - as in Dale's example - even allow the user to choose a new target, and bypass the resolver.

Alas, we can't allow the users just to specify at random a target to which the URN is to be passed. Users must also tell which service they want, unless there is globally supported default (for instance, URI to Resource). And, since the resolver does not know which protocols the server supports to deliver the service the user is asking for, the user should specify the protocol as well. In Dale's example, it would be Z39.50 to retrieve metadata. If the user does not know the protocol, the resolver can make a port scan to see if there is for instance an SRU server up and running on the target server. If a suitable server is found, the resolver should be able to convert the URN into a proper form, for instance into an SRU query with the NSS (e.g. ISBN) as a search term. The server would then send to the user metadata about the resource.

> (though it would have been less useful when the name was initially

Or, instead of using the server the user preferred, the URN resolver can 
utilize one of the pre-configured servers. And if the identifier is 
semantic, parsing the NSS will provide a hint on where to go. For 
instance, if the user is interested in a book which has an ISBN that has 
been assigned in New Zealand, the resolver may be able to locate the 
national bibliography of New Zealand, and pass the request there.

As an aside, queries will definitely be less stable than namespace 
specific strings, since although a document may exist a very long time, 
services related to it will be more short lived. 100 years from now it 
may still be possible to retrieve an ancient PDF version of Ulysses 
(which by then will no longer be accessible without digital 
archaeology), but metadata formats will have changed so that getting a 
MARC 21 record would be challenge.

Best regards,

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Jul 2014 10:55:09 +0200

Hi everybody,

I think it would be good if we could keep focused on "what is wrong with 
RFC 3986 from the URN community's point of view".

> communities which prefer URNs and other persistent identifiers do not

I don't see any action coming out of this :-)

> that URLs are equally good as names as URNs.

Also, it doesn't say that URLs "are equally good as names". What it 
*does* say is:

"An individual scheme does not have to be classified as being just one 
of "name" or "locator". Instances of URIs from any given scheme may have 
the characteristics of names or locators or both, often depending on the 
persistence and care in the assignment of identifiers by the naming 
authority, rather than on any quality of the scheme. Future 
specifications and related documentation should use the general term 
"URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]."

If your concern is that RFC 3986 says "stop to say 'URN'" then we can 
think of relaxing that advice in an erratum.

So my understanding is that some people over here want to say that URNs 
are not URIs. I don't see how this can be discussed in a useful way 
*unless* somebody comes up with a concrete list of things that they 
believe to be "wrong" in RFC 3986.

Also I'll repeat what somebody else pointed out already: making this 
fork essentially means that those new URNs can not be used in places 
where we currently allow URIs in protocol elements, and that they may 
not be processed correctly by existing libraries that expect URIs. Is 
this really the intent?

Best regards, Julian

---

From: Juha Hakala <[email-masked]>
Date: Fri, 11 Jul 2014 14:59:40 +0300

Hi Julian,

On 11.7.2014 11:55, Julian Reschke wrote:
> have the characteristics of names or locators or both, often depending 
> on the persistence and care in the assignment of identifiers by the 
> naming authority, rather than on any quality of the scheme. Future 

That would be fine.

If the expectation was that as a result of RFC 3986 and promotion of 
cool URIs the usage of URNs and other persistent identifiers would 
gradually diminish, then that has definitely not happened. On the 
contrary, popularity of e.g. Handles and DOIs is increasing. Already 
more than 100 million of the latter have been minted, and it is likely 
that there are even more Handles around (but nobody knows how many).

So it seems that we shall have at least two different but complementary 
approaches to naming things in the Internet. Cool URIs like this

http://viaf.org/viaf/54202464

may be operational even for decades, but this name / identifier is not 
standard-based, it is dependent on technical infrastructure maintained 
by a OCLC, and it depends on HTTP and a domain registered by that firm. 
On the other hand, urn:isni:0000000109022386 refers to the same public 
identity than the HTTP URI above. As a standard identifier ISNI ID has 
stronger administrative basis that the VIAF ID, and it is not protocol 
dependent. Therefore ISNI-based URN is likely to have longer life time 
than VIAF-based HTTP URI. Alas, there is no way to make URNs in the 
URN:ISNI namespace actionable yet.

>
>> ...
>
> So my understanding is that some people over here want to say that 
> URNs are not URIs. I don't see how this can be discussed in a useful 
> way *unless* somebody comes up with a concrete list of things that 
> they believe to be "wrong" in RFC 3986.

On the basis of what you and Dale have written recently, would it be 
possible to a) relax the "stop to say URN" advice because there are 
communities which see a need for URNs and other persistent identifiers, 
and, related to that, b) make it more clear that from IETF point of view 
there are both identifiers and names, and to explain the difference 
between the two so that even the non-initiated ones can understand it? I 
had no problems grasping the difference between URLs and URNs, but 
sometimes I feel that it would be easier to grasp the holy Trinity than 
the combination URIs, URNs and URLs :-).

> not be processed correctly by existing libraries that expect URIs. Is 

No. Allowing the usage of queries in URNs should not cause any problems 
in systems that are able to process URIs. Organizations developing URN 
resolver applications need to modernize the existing tool packs so that 
the applications can deal with the resolution requests encoded in URI 
queries by rendering those URNs into appropriate HTTP URIs. But this 
should not have an impact to the rest of the Internet.

We all just have to live with the terminological differences between us 
and IETF / W3C. It is a bit late now to align the use of e.g. terms 
identifier and name in our respective communities. We just have to be 
aware of the complexities that follow from this terminological mismatch.

   All the best,

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 11 Jul 2014 11:56:23 -0400

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

> currently allow a URI or an IRI.

That paragraph seems to me to be a good start on the requirements for
this discussion!

>     is defined in terms of IRI.

I am not experienced in IRIs, but it appears to me that the fact that
there is a canonical mapping of IRIs into URIs (and the reverse) means
that IRIs and URIs used together are a solution to the conflict
between the needs of "display" and "on-the-wire" use.  This would seem
to solve many of the internationalization problems.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 11 Jul 2014 13:18:57 -0400

> Date: Fri, 11 Jul 2014 11:20:56 +0300

There seem to be a number of intertwined issues here, only some of
which have been directly addressed in the discussions that I have
seen.  I will attempt to address them in the order that makes
conceptual sense to me, rather that in the order in the original.  Of
course, my order is flavored by my background as an engineer.

I think everyone agrees on what "URI" means -- all the things defined
by RFC 3986.

The meaning of "URL" and "locator" is less well-defined.  It seems
that anything which can be used in a standardized way to retrieve a
resource is considered a "locator" and a URI that one expects to be
able to use as a locator is a URL.

So URIs with the http: scheme are URLs.

But now we run into one of those extension/intension things:  (
http://www.britannica.com/EBchecked/topic/289860/intension-and-extension
) Everyone expects that an http: URI can be used to retrieve something
via HTTP.  But of course, that need not be true for any particular
http: URI -- I once used an http: URI as the name of an XML schema,
and you couldn't use it to retrieve anything.  So it actually was a
name but not a locator, despite that it had the http: scheme.

So even though URIs with the http: scheme are considered URLs,
sometimes one of those URIs isn't really a URL.  But the definition of
the http: scheme makes it clear that the main, intended usage of the
scheme is for locators to be used with the HTTP and HTTPS protocols.

Currently, the meaning of "URN" is the URIs with the urn:  scheme.
The distinguishing feature of that scheme is that it is required to be
administered in a way that ensures that those URIs are high-quality
names.

This shows the general tendency to define/manage schemes so that each
scheme has an understood role, the URIs in a scheme can be
consistently used as generally as locators or names, and thus URIs in
those schemes are generally called URLs or URNs.  But as Juha notes,
this is explicitly not required generally:

And there are other sets of name identifiers, like DOIs and handles.
But they aren't URIs -- they are neither registered as such nor do
they conform to the URI syntax.

> >     have the characteristics of names or locators or both

It does appear to me that people have not always used the term "name"

> extensible naming system".

But clearly that is using the term "name" in a way that we have not
been doing here, because many schemes are understood to have no
particular permanence properties.

Here, we've been using the term "name" to be identifiers whose meaning
is "permanent", at least to the point where the resource can be moved
to different physical or network locations without having to change
its name.

> This allows the use of e.g. HTTP URIs as names.
[...]
> communities which prefer URNs and other persistent identifiers do not 

URNs are superior compared with URLs as names *by intension*, because
the standards for the urn: scheme require that their definition make
them high-quality names.

It seems to me that someone could define a group of http: URLs and
administer them with sufficient rigor that they would be high-quality
names.  This would make them names by extension but not by the
intension of their scheme.

Juha says "The communities which prefer URNs and other persistent
identifiers do not subscribe to" the idea that "both URLs and URNs can
be administered well enough" to be used as high-quality names.  I
think it is important to get a more thorough explanation of why they
do not think this is so.

> that URLs are equally good as names as URNs.

Neither of those objections stems from the *syntax* of URIs.  But they
do stem from the "URI community" and need to be addressed.

In regard to the first point, "the term URN can be deprecated in
favour of URI", Juha quotes Wikipedia ("Uniform resource name"):

    Since RFC 3986 in 2005, the use of the term has been deprecated in
    favor of the less-restrictive "URI", a view proposed by a joint
    working group between the World Wide Web Consortium and the IETF.

In RFC 3986 section 1.1.3, this is stated:

    Future specifications and related documentation should use the
    general term "URI" rather than the more restrictive terms "URL" and
    "URN" [RFC3305].

and that sentence seems to reference RFC 3305 section 2 (which I will
not quote whole).

But I don't see much in section 2 that is particularly important to
this discussion.  Its main import seems to be that people have used
"URL" (and possibly "URN") where they really mean "URI" (the universe
of all RFC 3986 identifiers) and they should use the generic "URI"
unless they mean a specific subset.  It does give this example about
URNs:

   "urn:" is also a URI scheme; it defines subspaces, called
   "namespaces".  For example, the set of URNs, of the form
   "urn:isbn:n-nn-nnnnnn-n", is a URN namespace.  ("isbn" is an URN
   namespace identifier.  It is not a "URN scheme", nor is it a "URI
   scheme.")

But that seems to me to be completely compatible with everything both
Juha and I have been saying -- "isbn" is a URN namespace, not a
scheme.

So I don't see anything in the documents which intends that "URN" has
been deprecated in favor of "URI" -- in situations where it is
intended to only consider identifiers that are URNs.  Looking at later
RFCs, there are a zillion that define new URN namespaces, but I
suppose those aren't true counterexamples.  But RFC 7255 ("Using the
International Mobile station Equipment Identity (IMEI) Uniform
Resource Name (URN) as an Instance ID") uses "URN" repeatedly, and it
was approved by the IESG.  I don't see that there is any attempt to
deprecate the term URN, when it is used properly.

In regard to the second point, "URLs are equally good as names as
URNs", I suppose it depends on intension vs. extension.  Clearly, the
*definition* of http: URLs does not require that they have name-like
properties.  But as long as one has administrative possession of a
group of http: URLs, one could *manage* them as names, their extension
would be names.

But of course, that sort of management has "intension" problems, as
the applicable standards don't require that they are managed, or that
they are names.  You can't tell by looking at it that it is a name
(and perhaps might be called a URN).

I don't see how any reformation of the URN *syntax* will eliminate
that problem, because people will always be able to get allocation of
some subset of URIs, manage them as names, and use them as names.  The
only way to avoid that would be if (1) there is an explicit separation
of URNs and URIs, and (2) there is bureaucratic enforcement that
nobody may use a URI as a name.  Then we could ensure that a string
used as a name would be a name by intension, that it would fall under
a standard that required its management as a name.

I don't see how the bureaucratic enforcement could ever be
implemented.

The remaining portion of Juha's message concerns the practical or
engineering aspects of using queries with (or as part of, depending on
how you define it) URNs.  And he's got more experience regarding that
than I do, so I will not comment.

> Date: Fri, 11 Jul 2014 14:59:40 +0300

> that there are even more Handles around (but nobody knows how many).

Which suggests that there are requirements that URN schemes do not
satisfy.  I would like to see a report from the communities that
developed these identifiers as to why they did not adopt URNs.  In the
case of DOIs, it appears that they have declined to even embed the DOI
space into the URN space as a namespace.

> URN:ISNI namespace actionable yet.

That is a practical problem.  It seems that there was an idea to have
a uniform way to locate global resolver services for URNs, but it was
never broadly implemented.

I would not be surprised if that was because the developers of other
identifier systems had requirements for their resolvers that did not
fit under the proposed generic resolver services.

The great advantage of http-based "cool URLs" is that it requires no
new infrastructure in the client, which greatly eases introducing a
new resolution process.

> I had no problems grasping the difference between URLs and URNs, but
> sometimes I feel that it would be easier to grasp the holy Trinity
> than the combination URIs, URNs and URLs :-).

The sets are structured as follows.  Identifiers exist at all locations
marked "XXX".  (Or at least, they can exist.  I don't know if there
are any URIs which truly qualify both as URNs and URLs.)

    +----- URI (RFC 3986) "identifiers" ----------+
    |                                             |
    |  XXX                                        |  XXX
    |                                             |
    |  +---- URN (RFC 2141) "names" ----+         |
    |  |                                |         |
    |  |  XXX                           |         |
    |  |                                |         |
    |  |              +---- URL "locators" ----+  |
    |  |              |                 |      |  |
    |  |              |  XXX            |      |  |
    |  |              |                 |      |  |
    |  +--------------------------------+      |  |
    |                 |                        |  |
    |                 |  XXX                   |  |
    |                 |                        |  |
    |                 +------------------------+  |
    |                                             |
    |                                             |
    +---------------------------------------------+

> aware of the complexities that follow from this terminological mismatch.

Yes, that is often true.

Dale

---

From: Michael Mealling <[email-masked]>
Date: Fri, 11 Jul 2014 14:04:31 -0400

What Dale said below is where the rubber always met the road for me. The difference between a URN and any other URI scheme is the following:

Nothing found in RFC 2616 or elsewhere that defines the 'http' scheme tells my software whether 
http://whitehouse.gov/ 
is maintained with sufficient rigor to qualify as "long lived" (the identifier, not the thing it identifies). If I make the assumption that it is and something changes at whitehouse.gov that violates my assumption then that is MY error. It is hard to design protocols based on assumptions.

BUT, in RFC 2141 there IS a statement that if I see
urn:isbn:whatever
that I can safely and correctly rely on that identifier being forever bound to the resource (whether that resource is physical, electronic, or metaphysical). If something violates that assumption then I can know that SOMEONE ELSE has made an error. 

By using 'urn:' over 'http:' you are making an explicit statement about your intent as verified by the URN registration mechanism.

-MM

I'll go back to lurking now...

Michael Mealling
+1-678-640-6884	@mmealling

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 11 Jul 2014 17:55:41 -0400

Juha raises objections to "cool URLs" (great name!) like

when

    urn:isni:0000000109022386

is more correct in a lot of ways.

But I notice that the URL is truly usable as a locator, and is in
practice usable as a name.  (Thus, it inhabits the magic realm of the
intersection of URLs and URNs.)

The URN, on the other hand, is a high-quality name in every way, but
in most situations it isn't usable as a locator, because there isn't a
default, generic resolution service for URNs.  If someone set up a
resolution service, that would help, but they'd also have to get the
users to each install the proper client software.

What happens in practice?  The technique that is easy to install and
use is adopted rather than the one that is technically best.

Dale

---

From: Larry Masinter <[email-masked]>
Date: Sat, 12 Jul 2014 05:34:37 +0000

The fact that some communities have a different use of the
same terms is inevitable, but not grounds for changing
the specification, just for being careful editorially.

Name/identify/locate are verbs; which is more
appropriate depends on the action implied. 
name/identifier/locator are nouns, and, as pointed
out frequently, do not form distinct categories, 
because the same ID can be used to name and to locate.

I think URNbis needs to reserve urn: names that
are assigned and authoritatively resolved by organizationally managed
processes. Some may indeed intend to be around "forever" but
there is no assurance, for example with provisional NIDs.

URNbis should focus on (re)defining "urn:",  because that is what it 
is chartered to do.

> that are called URNs. 

'Memory institutions' should be interested in preserving the memory
of the actual focus of creative works which are difficult to identify
and talk about using the older library perspective of an archive
consisting of an unordered collection of objects with associated
metadata.  The architecture (identifiers for works, works self-contained, 
works retrievable and functionally independent) work OK for
electronic publications which recapitulate the affordances of physical
media. But more and more creative works are linked nests of experiences
which don't decompose easily into identifiable components
independently exchangeable. The  intuitions from decades of 
experience are insufficient. 
 
> Which means that the problem is:  Does the set

Even for currently deployed and archived content, the traditional
Identification methods are inadequate to describe new media.
For this and other reasons, I don't think "sufficient for the needs
of memory institutions" is the right sufficiency criterion.

And the XRI specification exposes several perceived requirements
of memory institutions for traditional material that the URN proposals
don't seem to address.
 
> parts of the URI space won't work for memory (and aren't even intended

The strings by themselves do nothing, it's the systems and protocols
that use them that do the work. Perhaps allowing namespace 
authorities to publish (in the IANA NID registry) APIs or protocols or
other methods for name assignment and resolution would allow
memory organizations to decide which URIs they will or will not
accept as authoritative and well-managed. 

Repeat 'xri' comment.

> > >  resource within the scope of the URI's scheme and naming authority

"contains" should have been "generally contains" or "is intended to
contain" or "might contain", since there are lots of uses of queries.

> > authority. Obviously not all URIs with query are identifiers after all.

I think there is some problem with taking these sentences out
of context and staring at them too hard. This "within the scope" phrase
is elaborated in the (just published) RFC7320/BCP190: 

      " for example, if a specification documents that the "sig"
        URI query parameter indicates that its payload is a cryptographic
        signature for the URI, , it can lead to undesirable behavior."

> http:/https: and sip:/sips: schemes.  

Actually, http/https don't define the use of "query". HTML has a
convention for packing text form data into a HTTP URL for a
whose method is GET. But HTTP itself doesn't look in the query
or assign it any semantics other than sending path + query to
the server (see RFC 7230).

'mailto' defines query parameters for preloading mail headers
(subject, body). 

> And indeed, the generic urn:

I don't see how introducing these features for *all* URNs is feasible;
whether the resource identified has metadata or is locatable 
depends on the URN namespace and the name within.
 
> > resolution services the users want.  

You're mixing into the URN-for-naming which has certain 
managed properties with the URL-for-retrieving, which is 
more transient without managed processes. For example,
you want to add a query interface for obtaining metadata
without any method for resolving disputes about what
metadata applies, or changes in metadata meaning, syntax,
or scope.

> If the application handles the URI "opaquely", that is,
> behavior by changing the query part. 

Changing the query part isn't handling the URI "opaquely".

>     urn:isbn:0-395-36341-1?metadata

This is backwards.  The "?metadata" does not exhibit any of
the managed process promise of permanence.  Prepending
"http://metadata.org/" is more appropriate than appending
"?metadata". 

>   In a philosophical way, we can consider the metadata to be
> part of the resource that is the book <urn:isbn:0-395-36341-1>. 

Unless the metadata includes attributes like "price on Amazon"
or "content rating" or "copyright license status". 

> OTOH,

I don't understand how this identification is more "only mental"
than any other URI.

> URN of the underlying "book" by deleting the query part to obtain:

Removing opaqueness.

> <urn:isbn:0-395-36341-1?data> must be used ...)

Not really relevant but instructive.

>     urn:isbn:0-395-36341-1?resolver=z3950.loc.gov

or
   resolve://z3950.loc.gov/urn:isbn-395-36341-1

would be a better URI. Again, xri does this, although in a
more principled way.

I'll send a separate note about the privacy implications
of distributed URN resolution.

> in some way for this particular retrieval task.

This is more like choosing which proxy to go to.

> DNS, the application can *algorithmicly* remove the query to obtain

Removing a 'resolve://host/' prefix is as easy as removing a '?resolver='
suffix, without polluting existing URNs.

> which can be assumed to be more semantically stable than the above
> URN (though it would have been less useful when the name was initially
> used).

resolve: or xri: URIs are semantically stable.

> I think everyone agrees with you on those points.

I think the scenario is wishful thinking, and no change
to IETF documents will make it work.

> in an awkward escaped way.  

Of course you could allow IRI urn: s. 

> that is not inconvenienced by any character that the string might

This issue is resolved for IRIs, which urn's could become.

> file name entry in Windows rarely needs to treat the space character

Until you go into cmd and type cd.

> the interface provides framing.  We could then standardize a mapping

If you say URNs are URIs then you can use the IRI mapping without
having to redefine all of the mechanisms.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 14 Jul 2014 16:52:03 +0900

Hello Barry, others,

Sorry for the delay of my answer to your AD interrupt.

> I'd like to throw in an AD interrupt designed to steer the recent

Thanks for this!

> as we update the specs for ISBN and the others.

Very good. Let's do it.

> different view and different needs in mind.

I don't understand why RFC 3986 wouldn't address the needs of URNs 
because the URN specs were written before RFC 3986. Wouldn't one assume 
that if RFC 3986 was written after the URN specs, it would have taken 
them into account? Wouldn't one assume that if this weren't the case, 
RFC 3986 wouldn't have passed IETF last call?

And that's pretty much the case. As others, in particular Julian, have 
already shown, neither syntax nor semantics in RFC 3986 in any way 
contradict what the URN specs currently say. As far as my (admittedly 
limited) understanding of the intended/planned 
extensions/additions/clarifications to the URN specs goes, there is also 
nothing in RFC 3986 that would contradict any such intentions/plans.

Granted, the terminology in RFC 3986 isn't exactly the terminology of 
the library community (because RFC 3986 was written for a much wider 
audience). But words are just words. If it turns out to be really 
heplful in the URN specs, there's nothing against e.g. writing "in this 
series of specifications, the term 'identifier'(*), in contrast to its 
meaning in RFC 3986, is defined as follows:". (*: replace with favorite 
term(s) of your own). I'm sure it wouldn't be the first RFC where 
something like this happened.

> proposal we have to keep in mind what this working group's goal is,

I just wanted to check on the goals, and for that I went to the charter. 
Among else, I found this interesting piece of text:

"There is a need to clarify that URNs are specific URIs (namely those
using the 'urn' URI scheme) and hence all general URI rules apply to URNs."

The charter also list the following items:
"For RFC 2141, this revision will include in particular:
- an update of the formal syntax specification in the light of the
URI Standard (STD 66, RFC 3986) using the ABNF from STD 68
(RFC 5234);
- a formal IANA registration for the 'urn' URI scheme using the
current template from BCP 35 (RFC 4395);"

These items are easy to complete quickly. There's no problem starting 
some general considerations with "URNs are specific URIs (namely those
using the 'urn' URI scheme) and hence all general URI rules apply to 
URNs." and then immediately continue with "However, URNs have a number 
of special properties not shared generally by other URIs...".

The syntax update and the registration are likewise just formalities.

> or best way,

<warning kind='explicit content'>
John's proposal is neither the right nor the best way. It's actually 
just unnecessary, confusing, and distracting the WG from the necessary 
technical work.
</warning>

> but that has to go with a technical discussion of an

Like others, I'm not seeing *any* conflict here whatsoever. The unified 
theory is indeed unified, but extremely loose. It's *on purpose* made 
lose enough to accommodate almost everybody and everything, including URNs.

What may be more of a problem (and you may be in a good position to tell 
us whether it is or not) is that the growing set of disparate 
communities comes with too disparate expectations for URN namespaces. 
But that would be a problem that would have to be solved *within* URNs.

To give some analogies for why splitting URIs and URNs is a bad idea, 
what would the average IETF participant say to a proposal to separate IP 
addresses for clients and for servers? Such a proposal would be 
completely natural for somebody used to dumb terminals or the French 
minitel system.

Or what about the idea that we need completely separate address formats 
for unicast and multicast communication? Or that we need separate IP 
protocols for UDP and TCP and SCTP and whatnot. And there are other, 
similar analogies.

These analogies all have a rather clear criterion for separation, but 
the benefits of an overall (loose!) unification are bigger in every 
case. And the overall loose unification doesn't preclude differentiation 
at the next level.

> proposed, we have an alternative proposal that keeps us moving in the

My proposal is to do the actual technical work we are chartered to do, 
in true IETF fashion. (If we aren't clear about what that means, we 
might try to start with a requirements statement.)

I plan to send a mail (or split it up into a few mails) in a thread with 
Juha which I hope will contribute to the technical work. But owning to 
my day job, I won't be able to send more than one or two mails a day.

Regards,   Martin.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 14 Jul 2014 14:19:35 +0000

> On Jul 14, 2014, at 12:53 AM, "Martin J. Dürst" <[email-masked]> wrote:
> 
> Hello Barry, others,
> 
> I don't understand why RFC 3986 wouldn't address the needs of URNs because the URN specs were written before RFC 3986. Wouldn't one assume that if RFC 3986 was written after the URN specs, it would have taken them into account? Wouldn't one assume that if this weren't the case, RFC 3986 wouldn't have passed IETF last call?
> 
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 14 Jul 2014 15:29:38 -0400

If we really want to stop people from using "cool URLs" rather than
proper URNs (which are by standard subject to proper management
processes), we need to overcome the problem that there is no
easily-accessible resolution service for URNs.  And by
"easily-accessible resolution service", I mean "a resolution service
that someone can use without installing client software."

To that end, we could institute a redirector that behaves like this:

The user who is faced with the URN <urn:isni:0000000109022386> enters
into his browser something like this:

    http://urn.ietf.org/urn:isni:0000000109022386

The redirector at urn.ietf.org returns a 302 response that is directed
to whatever the actual HTTP-accessible resolution service is, with the
request reformulated into the format that the resolution service
expects.  Of course, urn.ietf.org would have to be provided with a
proper map for how to handle the various NIDs, and that map would have
to be maintained.

Over time, this would allow browser makers to add a special rule that
when a URN is entered into the address field, it can be automagically
reformatted into a URL request.

At that point, there would be no loss to information publishers from
presenting their URNs in proper URN format, rather than as cool URLs",
because URNs would function as links.

Dale

---

From: Juha Hakala <[email-masked]>
Date: Tue, 15 Jul 2014 10:37:07 +0300

Hello,

On 14.7.2014 10:52, "Martin J. Dürst" wrote:
> because the URN specs were written before RFC 3986. Wouldn't one 
> assume that if RFC 3986 was written after the URN specs, it would have 
> taken them into account? Wouldn't one assume that if this weren't the 
> case, RFC 3986 wouldn't have passed IETF last call?

One of URNBIS objectives is to update the URN syntax. There are both 
practical and theoretical reasons why aligning RFC2141bis with the 
syntax specified RFC 3986 is important.

On the other hand, it would be problematic from the URN community point 
of view to endorse this:

>     have the characteristics of names or locators or both, often
>     depending on the persistence and care in the assignment of
>     identifiers by the naming authority, rather than on any quality of
>     the scheme.  Future specifications and related documentation should
>     use the general term "URI" rather than the more restrictive terms
>     "URL" and "URN"

Back when URLs and URNs (locators and names) had not been merged under 
URI umbrella, one could tell that for instance 
"https://www.w3.org/International/wiki/IRIStatus" was just a locator. 
But according to RFC 3986 it is definitely both an URI and a locator, 
and given the naming policy of W3C, also a name. This can be a little 
confusing at times, and IMO not fully aligned with this point of view 
from Functional requirements for URNs (http://www.ietf.org/rfc/rfc1737.txt):

> A URL identifies the location or a container for an
>     instance of a resource identified by a URN.  The resource identified
>     by a URN may reside in one or more locations at any given time, may
>     move, or may not be available at all.

 From the RFC 1737 point of view, names and locators are different:

> It is strongly recommended that there be a mapping between the
>       names generated by each naming authority and URLs.  At any specific
>       time there will be zero or more URLs into which a particular URN
>       can be mapped.  The naming authority itself need not provide the
>       mapping from URN to URL.

Try replacing all instances of URL and URN above with URI ;-).

While RFC 3986 did not obsolete RFC 1737, but it is not fully aligned 
with its requirements. Let's take a closer look on how the term 
identifier is defined. URI syntax specifies identifier like this:

> An identifier embodies the information required to distinguish
>        what is being identified from all other things within its scope of
>        identification.

RFC 3986 says that "in many cases, URIs are used to denote resources 
without any intention that they be accessed". RFC 1737 definition is 
different in this respect (and in some other ways as well):

> The purpose or function of a URN is to provide a globally unique,
>        persistent identifier used for recognition, for access to
>        characteristics of the resource or for access to the resource
>        itself.

This difference does not need to be a problem; we just need to be aware 
that the term identifier has a different meaning in RFC 3986 and in 
URN-related RFCs. It may be possible to fix this by e.g. using 
systematically the term name instead of identifier in RFC 1737bis and 
other URN documents.

If locators can be also names, how can humans / applications tell which 
locators actually do have this double role? As Michael Mealling said in 
a recent message to this list:

> The difference between a URN and any other URI scheme is the following:
>

> extensions/additions/clarifications to the URN specs goes, there is 
> also nothing in RFC 3986 that would contradict any such intentions/plans.

Syntax is OK, in that respect the problem is just that the RFC 2141 is 
outdated.

I am not sure what you mean by semantics. But if URI and URN 
specifications have to use for instance the same definition of 
identifier, RFC 1737 needs a face lift. And if the URN community must 
approve of the idea that locators can be names and that in the future we 
need just URIs instead of URNs and URLs, then IMO semantics is a 
problem. At least this statement

> Future specifications and related documentation should
>     use the general term "URI" rather than the more restrictive terms
>     "URL" and "URN" [RFC3305].

should be relaxed so that URNs still have a niche. For instance, it is 
possible to say that URNs are special names which cannot be mistaken to 
be locators (and locators cannot be mistaken to be URNs).

> heplful in the URN specs, there's nothing against e.g. writing "in 
> this series of specifications, the term 'identifier'(*), in contrast 
> to its meaning in RFC 3986, is defined as follows:". (*: replace with 
> favorite term(s) of your own). I'm sure it wouldn't be the first RFC 
> where something like this happened.

Words may be just words, but IMO what IETF currently has in its hands is 
confusing. In the past there were just URNs and URLs which had distinct 
roles and which humans and machines could easily tell apart. Now there 
are URIs, names and locators which have been specified in such a way 
that a URI can be just URI, URI and locator, or all three of these, and 
it is anybody's guess what the intention of the naming authority (if 
any) has been. And if the intention was that URI Generic Syntax is 
compliant with the spirit and letter of functional requirements / 
recommendations to URNs and URLs, the current situation does not seem to 
be fully satisfactory.

>> We're at a point, I
> Like others, I'm not seeing *any* conflict here whatsoever. The 
> unified theory is indeed unified, but extremely loose. It's *on 
> purpose* made lose enough to accommodate almost everybody and 
> everything, including URNs.

Sorry, but I don't think that RFC 3986 accommodates URNs or other 
persistent identifiers too well. But since hundreds of millions of 
persistent identifiers have been assigned since RFC 3986 was written it 
is fair to say that there are plenty of communities out there which do 
not think that it is OK to use locators as names. But there are also a 
lot of communities who are minting plenty of URIs without making it 
clear what these URIs actually are.

A quote from a colleague who has been closely involved with linked data 
projects:

> Yes, the Linked Data world initially took the viewpoint that creating 
> lots of identifiers wasn't a problem, as we could just owl:sameAs them 
> together.  In practice that is a nightmare, of course and as the 
> library world could have told them!  Now there's a trend as far as I 
> can tell towards fewer, more well known identifiers when possible. 
> ISBNs are a great example of this. 

URI gives anyone a privilege to create identifiers, and it looks like 
they have been taken for names even when such assumption is not correct. 
The quote above indicates that in order to make the Web work better, it 
is better to have a small set of well managed identifiers for important 
stuff than plenty of badly managed identifiers for everything out there.

>
> What may be more of a problem (and you may be in a good position to 
> tell us whether it is or not) is that the growing set of disparate 

One of the strengths of URN is that it can accommodate very different 
communities. Having said that, there are some limits: I have a problem 
with a) namespaces in which the URN assignment is not a well managed 
process, and b) namespaces which do not intend to provide any resolution 
services. These namespaces undermine the value of the URNs as a whole.

> what would the average IETF participant say to a proposal to separate 
> IP addresses for clients and for servers? Such a proposal would be 

We have not been talking about technical split. It is possible to 
disapprove the view that locators can be names, and create URNs which 
are fully compliant with the URI Generic Syntax.

>
> Or what about the idea that we need completely separate address 
> formats for unicast and multicast communication? Or that we need 
> separate IP protocols for UDP and TCP and SCTP and whatnot. And there 
> are other, similar analogies.
>
> case. And the overall loose unification doesn't preclude 
> differentiation at the next level.

I wish I could understand what the benefits of introducing URIs have 
been...

> might try to start with a requirements statement.)

I would not mind leaving the further development of URIs (if any) to 
IETF and future WGs. What both IETF and the persistent identifier 
community (which encompasses much more than just libraries) need from 
URNBIS is a URN syntax fully aligned with RFC 3986 (so that it is 
possible to use query and fragment), more efficient namespace 
registration process and a workable means for specifying resolution 
related services and service parameters. If URNBIS fails to deliver, 
there is a risk that URN specifications will be modernized elsewhere, 
and then IETF would no longer have any persistent identifier systems 
under its wing - unless a decision is made to endorse ARKs.

Juha

>
> I plan to send a mail (or split it up into a few mails) in a thread 
> with Juha which I hope will contribute to the technical work. But 
> owning to my day job, I won't be able to send more than one or two 
> mails a day.
>
> Regards,   Martin.
>
>
>> Barry, Applications AD
>>

-- 

  Juha Hakala
  Senior advisor

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 15 Jul 2014 18:46:21 +0900

Hello Juha, others,

> and given the naming policy of W3C, also a name.

I'm not sure "https://www.w3.org/International/wiki/IRIStatus" is the 
best example. I think a better example would be 
http://www.w3.org/XML/1998/namespace, the URI of the xml: namespace. 
This was already mentioned in previous mail. It is used in many contexts 
where identification is crucial, but retrieval is secondary or 
unnecessary. In the name/locator dichotomy, this gives it a lot of nameness.

What is the problem with such URIs from the point of view of the URN 
community? In my understanding, what the URN community needs is that 
URNs work as "names", and that's the case currently and isn't changed in 
any way by RFC 3986. It would be strange if the URN community would want 
to prohibit other communities from experimenting, implementing, and 
deploying various ways to combine properties of identifiers.

> This can be a little

This is a *very* old document, over 20 years old, from the very early 
days of the Web. Fortunately, one of its authors (Larry) is on this 
list, so maybe he can say some more about it.

Also, it is a requirements document. In the IETF, as far as my 
understanding and experience goes, requirements documents are just used 
as part of the development process, but do not carry any force 
afterwards. As you can see, RFC 1737 is classified informational, which 
I guess is true of most if not all requirements documents. If the actual 
specs produced afterwards are different than the requirements document, 
e.g. because it turned out that some of the requirements were too 
ambitious, or that the WG or the IETF as a whole decided on a different 
path, then that's just the way it is. At least in general, requirements 
documents aren't revised or obsoleted or anything, they are just left 
around as historic background.

> Try replacing all instances of URL and URN above with URI ;-).

That indeed doesn't work. But there's no problem translating this into 
"modern" language. The short version might look something like this: "It 
is strongly recommended that URNs can be mapped to resolvable URIs."

> systematically the term name instead of identifier in RFC 1737bis and

Yes indeed. There are various different ways to deal with terminology, 
and this is indeed one of the better ones.

> locators actually do have this double role?

Well, sometimes they can, sometimes they can't. Sometimes they will 
care, some other times they won't. Let's look at the classical example 
from Architecture of the World Wide Web, Volume One 
(http://www.w3.org/TR/webarch/): http://weather.example.com/oaxaca. If 
this serves today's weather in Oaxaca, then it's probably not something 
the library community cares about, but to people using it daily, it's a 
semi-permanent fixture in their lives, even if the actual weather it 
shows will change a lot (as the weather has a tendency to do).

> As Michael Mealling said in
>> http://whitehouse.gov/ is maintained with sufficient rigor to qualify
>> as "long lived" (the identifier, not the thing it identifies). If I
>> make the assumption that it is and something changes at whitehouse.gov
>> that violates my assumption then that is MY error. It is hard to
>> design protocols based on assumptions.
>>
>> that I can safely and correctly rely on that identifier being forever
>> bound to the resource (whether that resource is physical, electronic,
>> or metaphysical). If something violates that assumption then I can
>> know that SOMEONE ELSE has made an error.
>>
>> By using 'urn:' over 'http:' you are making an explicit statement
>> about your intent as verified by the URN registration mechanism.

That's just fine. By using http: over urn:, the White House isn't
making such a statement. Do they need to make such a statement?

By using http://www.w3.org/XML/1998/namespace, the W3C isn't taking 
advantage of the urn: convention, but they still can promise to keep 
this identifier permanent. Do they *need* to use urn:?

> Syntax is OK, in that respect the problem is just that the RFC 2141 is

Okay, great.

> identifier, RFC 1737 needs a face lift.

As I said above, requirements documents aren't updated in the IETF.

> And if the URN community must
> approve of the idea that locators can be names

Why do they need to approve? If something starting with http: is used as 
a name, then isn't it just a name?

> and that in the future we
> be locators

The updated URN spec(s) can very well say something along these lines.

> (and locators cannot be mistaken to be URNs).

If URN means just things starting with urn:, then I think it's obvious 
that schemes with other prefixes cannot be confused with urn:.

> recommendations to URNs and URLs, the current situation does not seem to

One of the main goals of IETF specs is to be in line with practice. The 
observation leading up to RFC 3986 was that the boundary between names 
and locators, although very clear in some cases (e.g. libraries), isn't 
as clear cut in other cases. That doesn't mean that there can't be 
scheme prefixes (urn: would be the classical example) where the boundary 
is very visible and the position of the scheme is very clear.

> persistent identifiers too well.]

In the sense that it says that there can be all kinds of schemes and 
identifiers that may have different degree of "nameness" or 
"locatorness" or other properties, it doesn't give much of a special 
place to URNs or the urn: scheme indeed.

> But since hundreds of millions of
> not think that it is OK to use locators as names.

That's just okay. Nobody is telling anybody that they should mint http: 
URIs as names if they don't want.

> But there are also a

That's probably just fine. RFC 3986 isn't inhibiting this in any way.

> stuff than plenty of badly managed identifiers for everything out there.

Well, that's most probably true. But managing identifiers well is 
expensive. For some purpose, this expense may not be justified.

> process,

I guess that should go without saying.

> and b) namespaces which do not intend to provide any resolution
> services.

Well, first, up to now providing resolution services wasn't exactly 
easy. Some specs existed, but not much in terms of actual technology. Of 
course this may change. Second, there may indeed be URN namespaces that 
from the beginning didn't intend to provide any resolution services, for 
whatever reason. I don't think it would be possible to force them 
retrospectively to provide such services.

> We have not been talking about technical split.

If John's document isn't a technical split, then it would be good if it 
clarified what kind of split it is. But that's probably for John to do, 
not for you.

Regards,    Martin.

> It is possible to

---

From: Larry Masinter <[email-masked]>
Date: Thu, 17 Jul 2014 22:28:29 +0000

I wanted to summarize my position.

a) I don't think any changes to 3986 are actually necessary to
    allow URNbis to do what is requested, although some
    changes would be useful.

b) splitting URNs from URIs is harmful to many use cases.

c) what is being suggested (and motivating) -- adding query 
     parameters -- is actively harmful for non-document
    applications of URNs

d) The threat that some other group will redefine URN
    for their own purposes has already happened, although
   they were polite enough to call it 'xri' and not 'urn'.

e) The privacy impact of the underlying system architecture --
   that URNs would be sent to a service which would provide
    location information for the name -- has terrible 
    privacy implications. 

f) The actual modern needs of 'memory institutions' 
    for identification and as keys in indexing systems
    goes far beyond those represented here. The 
   'systems' track of the annual IS&T Archiving conference
    http://www.imaging.org/ist/conferences/archiving/
    is a good source of reference for the range of 
   identification issues that need solutions for which
   URNs are inadequate, no matter how tarted up.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 17 Jul 2014 22:36:41 +0000

g) convincing people to use urns instead of 'Cool URLS' should not be a goal.
    Yes, it adds a level of indirection, but the extra level doesn't buy much
   and it adds another failure point.

---

From: Juha Hakala <[email-masked]>
Date: Fri, 18 Jul 2014 11:15:56 +0300

Hello Larry; all,

>     and it adds another failure point.
There are people out there who think that the extra level does buy much.

A quote from a recent discussion on BIBFRAME list where librarians and 
system developers talk about linked data:

> On Jul 17, 2014, at 4:45 PM, "Denenberg, Ray"<[email-masked]>  wrote:
>
> What would be the benefit of representing an isbn as a urn if it doesn't resolve?
>
> Ray

> Speaking for a moment while wearing my software engineer's hat, some advantages are:
>
> 1) A uniform form for identifiers in managed data. Knowing that the identifiers in our data will appear as URIs allows us to make low-level assumptions about indexing and validation that aren't available over generic strings, leading to tools with better performance at lower cost.
>
> 2) A much shorter road to creating "resolvability" for those identifiers that lack it. Creating, managing, and sharing a resolution mechanism for some particular kind of URN is much more straightforward than creating such a mechanism for generic strings.
>
> ---
> A. Soroka
> The University of Virginia Library
>

Of course, if a URN were actionable, the benefits of expressing an ISBN 
as URNs would be even greater.

There are a lot of people out there who are already convinced that using 
persistent identifiers such as URNs instead of Cool URLs is a good idea 
or even essential. They don't need any more convincing, they want 
modernized URN standards. There are also a lot of people - mainly those 
who don't need to preserve digital content for long term (decades, even 
centuries) - who believe that persistent identifiers are not worth the 
trouble. It is impossible for the one group to convince the other that 
they are wrong. Arguments made are brushed aside as irrelevant.

But as usual in cases like this, time will tell which group is correct.

IETF is caught in a crossfire and has to decide how to perform a 
balancing act between URN-believers and non-believers. Such decision 
will be a political one, since technical issues we are debating will 
remain unresolved for the time being. What about adopting the view that 
there are Cool URLs and URNs out there, and list key arguments these 
camps are using to promote their system so that people reading these 
documents can make up their minds with the help of balanced 
information.  So, instead of just repeating a claim of the cool URL camp 
that the extra level of resolution does not give much added value, the 
URN community could list the actual benefits gained / achievable by 
resolving URNs.

>      allow URNbis to do what is requested, although some

Indeed. Since the adoption of RFC 3986 IETF has been sitting on two 
chairs, on the one hand saying that URIs have made URNs and URLs 
redundant, but in the same also maintaining a set of URN-related RFCs.
> b) splitting URNs from URIs is harmful to many use cases.
Perhaps; some practical examples of this would be nice.

On the other hand, saying that Cool URIs are sufficient and URNs are not 
really necessary is harmful from the URN point of view.
>       parameters -- is actively harmful for non-document

I don't see why there would be a problem like this. In practice, when 
URNs are assigned they will never contain either query or fragment. 
Queries will be added by client applications based on the requests of 
the end users who want certain kind of resolution services.

I am not sure of what you mean by non-document application of URNs. But 
even these applications may be able to support some resolution services. 
There is no reason why such services could not be requested by queries.

>     they were polite enough to call it 'xri' and not 'urn'.

As far as I am concerned, XRI extends URIs and IRIs, not URNs, although 
URNs can be embedded in XRI strings (just like they can be embedded in 
URIs). Had XRIs been mainly about URNs, it is unlikely that the W3C 
Technical Architecture Group would have bothered to recommend OASIS not 
to approve XRI as a standard.
>      location information for the name -- has terrible
I fail to see why the URNs would have more serious privacy implications 
than e.g. URIs or URLs. On the contrary. The key issue here is not 
technology but management.

URN (and other PID) resolvers are often maintained by the same 
organizations which administer the naming process and are responsible of 
the preservation of documents. From the point of view of privacy and 
security, this kind of managed environment is far better than the 
Internet in general. There are e.g. national libraries out there which 
guarantee that whatever you get when a URN is resolved will be the same 
thing for all practical purposes. Moreover, we take privacy seriously 
and do not share information which must be protected.

As far as I am concerned, cool URLs are less trustworthy than URNs from 
privacy and security points of view since it is impossible to know if a 
URL has been cool or not. Just one example: back in 2006, Henry Thompson 
said in URNs, Namespaces and Registries 
(http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html) that he 
"...now owns lccn.info and oclcnum.info". He then makes the following point:

> URIs can produce names which are very little different from the 
> equivalent myRI 
> <http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html#nri> 
> (compare e.g. http://lccn.info/2002022641 to |info:lccn/2002022641|), 
> while gaining all |http:|'s benefits of scalability and installed base.

URIs above turned out not to be cool at all, so I can see "http:'s 
benefits" from persistent identification point of view. Info URI 
initiative was discontinued in 2010, and there is nothing left of 
lccn.info domain. oclcnum.info is still there, but it has nothing to do 
with OCLC numbers any more. Looks like the owner of the domain has 
changed, since page http://www.oclcnum.info/ looks like some kind of 
Chinese marketing effort, which is not what Henry Thompson does.

Question to cool URI supporters: is the URI http://www.oclcnum.info/ 
cool because I still get something? Is it OK that some URIs are 
re-cooled every now and then?

As an aside, the book with the LCCN number shown above can now be found 
from

http://www.worldcat.org/search?qt=worldcat_org_all&q=2002022641

and no, there is no URN namespace for LCCNs.

Can't tell if this URL will still work 8 years from now. As far as I am 
concerned, trusting cool URIs or something I assume is a cool URI can be 
a serious security issue and it may have privacy implications as wello. 
There are already a lot of domains like oclcnum.info which have been 
taken over by companies which use them to lure in people who think the 
content has not changed. Of course, redirecting these web users to where 
they want to go is not at all in the interest of these tricksters.

>     URNs are inadequate, no matter how tarted up.

Memory institutions are not trying to solve all their identification 
issues with URNs.

As an aside, one of the organizers of IS&T archiving conferences  is 
NESTOR, German competence network for digital preservation. They use 
URNs a lot, and maintain a good summary page with links to various 
persistent identifier systems:

http://www.langzeitarchivierung.de/Subsites/nestor/DE/Standardisierung/PI.html

And the reason why persistent identifiers should be used in summarized 
nicely:

> Persistent Identifier dienen der eindeutigen und dauerhaten 
> Adressierung von digitalen Ressourcen. Im Gegensatz zu herkömmlichen 
> Web-URLs unterscheiden sie zwischen Identifizierung und Adresse einer 
> Ressource. Mit Hilfe eines Resolving-Mechanismus kann so 
> sichergestellt werden, dass auf eine Ressource auch noch zugegriffen 
> werden kann, wenn sich ihr physikalischer Speicherort verändert hat.

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Jul 2014 11:15:20 +0200

Hi Juha,

a few quick comments inline:

>> The University of Virginia Library

That's an argument for using URNs instead of plain strings (say ISBNs), 
not an argument of URNs in favor of "cool URIs". Actually, a "cool URI" 
has the same properties with respect to the two points.

> URN community could list the actual benefits gained / achievable by

That would be indeed useful.

> redundant, but in the same also maintaining a set of URN-related RFCs.

RFC 3986 doesn't say that.

> Perhaps; some practical examples of this would be nice.

You lose the ability to use URNs in places where URIs are expected.

> really necessary is harmful from the URN point of view.

Is any specification saying that?

>> werden kann, wenn sich ihr physikalischer Speicherort verändert hat.

That's misleading in that URNs do not "distinguish" between name and 
resolution, but simply do not *address* resolution.

Anyway.

The point of this thread isn't whether URNs are better than cool URIs, 
nor how resolution services ought to work. It's about whether there is 
any reason to accept John's proposal to "split URNs from URIs". Can we 
please focus on that?

Best regards, Julian

---

From: Andrew Newton <[email-masked]>
Date: Fri, 18 Jul 2014 14:22:14 -0400

>      parameters -- is actively harmful for non-document

Larry,

Can you elaborate on this? Can you provide a specific example?

-andy