Subject: [urn] updated URNBIS I-Ds

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 12 Jul 2013 12:09:29 -0600

I have updated 2141bis and 3406bis to the best of my ability,
incorporating what I perceive as agreement based on list discussion.
Naturally you might disagree with my reading of things, in which case
please post to the list, preferably with proposed text. We discuss open
issues at the IETF meeting in Berlin several weeks from now.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Juha Hakala <[email-masked]>
Date: Mon, 15 Jul 2013 15:32:30 +0300

Hello Peter,

> incorporating what I perceive as agreement based on list discussion.
Thank you for doing this; incorporating query and fragment into the URN 
syntax is an important step forward.
> issues at the IETF meeting in Berlin several weeks from now.
I have comments to chapters 6 and 7 (lexical and functional equivalence 
in URNs).

RFC 3986 does not make the difference between lexical and functional 
equivalence? Do we need to?

If we do (and I hope so), we need to clarify the text. The present 
version, parts of which come from RFC 2141, is a bit obscure since it 
does not refer to RFC 3986. And there are some bits which are IMO 
incorrect.

Assuming that we do not throw away functional equivalence, we should 
first say that what we call lexical equivalence is the same as 
equivalence specified in chapter 6.1 of RFC 3986. That is, we compare 
two URN strings to see if they are the same, and ignore fragment and 
query in the process. The resource itself is not retrieved; the 
principles for comparison should be (more or less) the same as those 
applied in RFC 3986.

The current I-D does not make it clear enough what we mean by functional 
equivalence. RFC 2141 says that two URNs are functionally equivalent if 
they are identical within a namespace. We have done away that 
unfortunate statement in Peter's draft; if two URN strings are identical 
within a namespace (as specified by RFC 3986) they must be lexically 
equivalent as well, and the other way around. A namespace cannot apply 
syntax that differs from RFC 3986.

Specified like this, functional equivalence does not seem to bring much 
added value. But given the nature of the URNs, we may say that analyzing 
functional equivalence involves retrieval of the resource. Then two URNs 
are functionally equivalent if they resolve to the "same thing".

Specified like this, we get some interesting differences between 
functional and lexical equivalence. First, two URNs from different 
namespaces will never be lexically equivalent but they can be 
functionally equivalent iff the outcome of the resolution process is the 
same. Second, these two URNs

urn:example:a123,456?s=U2C
urn:example:a123,456?s=U2L

are lexically but not functionally equivalent. Lexical equivalence 
ignores the query since we are just comparing the identifier strings. 
But the outcomes of the resolution processes will differ. In the first 
example it is the resource itself, in the latter a URL from which the 
resource can be retrieved.

Analyzing functional equivalence makes sense for URNs, since we have a 
limited set of well specified services. I am in favour of keeping the 
functional equivalence chapter, but in an edited form. It is definitely 
not right to say that functional equivalence can be determined within a 
given namespace since (as was pointed out in a previous version of the 
RFC2141bis) the same resource may receive URNs from multiple namespaces.

Juha

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503)
  FIN-00014 Helsinki University
  tel +358 9 191 44293

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 15 Jul 2013 15:06:59 -0600

On 7/15/13 6:32 AM, Juha Hakala wrote:
> equivalence? 

Section 6.1 of RFC 3986 does state:

   Because URIs exist to identify resources, presumably they should be
   considered equivalent when they identify the same resource.  However,
   this definition of equivalence is not of much practical use, as there
   is no way for an implementation to compare two resources unless it
   has full knowledge or control of them.  For this reason,
   determination of equivalence or difference of URIs is based on string
   comparison, perhaps augmented by reference to additional rules
   provided by URI scheme definitions.  We use the terms "different" and
   "equivalent" to describe the possible outcomes of such comparisons,
   but there are many application-dependent versions of equivalence.

It seems to me that "considered equivalent when they identify the same
resource" is "functionally equivalent", whereas "determination of
equivalence ... based on string comparison" is "lexically equivalent". I
was trying not to change RFC 2141 very much, which is why I left in the
phrase "lexically equivalent", but I would be happy to remove the word
'lexically' throughout 2141bis.

> Do we need to?

I don't think we need to.

> Assuming that we do not throw away functional equivalence, 

As RFC 3986 points out, the concept of functional equivalence is not
really actionable in practice, so I think it would be best to remove it.

> we should

I see no reason why they would be different at all. We simply need to
say which methods of equivalence checking are applied.

> are functionally equivalent if they resolve to the "same thing".

This is what RFC 3986 says, too. But why is functional equivalence
useful? And, from the perspective of the document, why is it important
and valuable to specify what functional equivalence might mean?

> same. 

IMHO that is analogous to the following sentences from RFC 3986:

   Even though it is possible to determine that two URIs are equivalent,
   URI comparison is not sufficient to determine whether two URIs
   identify different resources.  For example, an owner of two different
   domain names could decide to serve the same resource from both,
   resulting in two different URIs.

> Second, these two URNs

Is that fundamentally different from general URI equivalence checking?

> RFC2141bis) the same resource may receive URNs from multiple namespaces.

And, following the domain name example above, it's possible that URNs
from different namespaces could identity the same resource.

However, I just don't think it's useful to describe this in 2141bis and
I propose that we drop all mention of functional equivalence. I think
RFC 3986 got this right.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Juha Hakala <[email-masked]>
Date: Tue, 16 Jul 2013 09:09:35 +0300

Hello,

On 16.7.2013 0:06, Peter Saint-Andre wrote:
>     has full knowledge or control of them.
This assumes that there are no applications which have full knowledge or 
control of resources. Applications in which persistent identifiers will 
be used, such as digital preservation systems and web archives, may not 
have "full knowledge or control" (whatever that means). However, it is a 
normal practice in these applications to calculate a checksum for all 
ingested documents in order to find out if a copy of the resource is 
already stored in the system. If a duplicate is found, and if the stored 
copy has another URN, then the system will know that these two URNs are 
functionally equivalent.
> For this reason,
There is nothing application dependent in checking with e.g. MD5 if two 
files are identical.
> equivalence ... based on string comparison" is "lexically equivalent".

Yes. And we have means for checking both kind of equivalences.

> I
This is fine only if we consider just lexical equivalence in rfc2141bis.

Be that as it may, we can / should remove some of the prose in chapter 6 
of the I-D and just refer to RFC 3986 and especially to the comparison 
ladder (chapter 6.2).
> really actionable in practice, so I think it would be best to remove it.
There are two practical reasons for keeping it:

1. It is possible to give two or more URNs to the same resource.

2. We have applications which know / can check easily if two resources 
are identical (based on checksums).

For practical reasons it is often important to know if two URNs are 
functionally equivalent. With digital archives and other preservation 
tools which have emerged mainly after RFC 3986 was written we have now 
practical methods for determining functional equivalence of URNs (and to 
some extent even URLs).
> say which methods of equivalence checking are applied.
I do. RFC 3986 says that fragment components (if any) should be excluded 
from the comparison, and that's fine. But URI Generic Syntax does not 
say anything about what to do with the query component. We have to make 
it clear that for URNs the query components should ignored when the 
lexical equivalence of two URNs is checked (but note that query 
components are essential in the evaluation of functional equivalence).
> and valuable to specify what functional equivalence might mean?

The world has changed a bit since RFC 3986 was written. Determining 
functional equivalence is important since the same resource can receive 
multiple URNs. We can easily find out in e.g. web archives and digital 
long term preservation systems if this is the case.

It is difficult to know how many duplicate URNs there will be. But there 
is a lot of overlap between the namespaces so we may have a lot of 
duplicates. For instance, a researcher may give a urn:uuid for a report, 
which in the national library's collection receives urn:nbn. The main 
difference between these URNs is that one is from a well managed 
namespace, the other is not.

There will be even more overlap between different PID systems. 
Publishers give DOIs to scientific articles in their repositories, and 
national libraries will apply NBNs in order to manage resolution. If we 
specify functional equivalence and a simple method for determining it in 
rfc2141bis, the same principles can be applied by other PID systems as 
well.
> Is that fundamentally different from general URI equivalence checking?

Yes, because RFC 3986 does not tell what to do with the query component.

It should be noted that our method of determining the functional 
equivalence of two URNs is not fully applicable to URIs in general. If a 
query can be anything it is not really possible / practical to determine 
functional equivalence. But if appropriate ways of using query have been 
nailed down in the service registry, it should be rather easy to check 
if two query components are identical. The analysis can be based on the 
URN string; there is no need to retrieve the resource.
> from different namespaces could identity the same resource.

Your logic is not quite correct here. The fact that the same resource 
may exist in two different places in the Internet has nothing to do with 
the duplicate identifier assignment.
> I propose that we drop all mention of functional equivalence. I think
What's in RFC 3986 is right, but we can and should extend the scope of 
RFC 3986 by telling what to do with query component and by providing a 
simple way of determining if two resources are identical and therefore 
providing some means for the evaluation of functional equivalence in 
practice.

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 16 Jul 2013 19:19:34 +0900

I agree with Peter here.

Let's just make a simple example. Assume that there are urn namespaces 
for individual issues of journals, and for 'last issue' of journals.
(that may not be a terribly good example, but I hope it's good enough to 
show the point).

For a journal that's published every month, a specific individual issue 
and the 'last issue' will be "functionally equivalent" for a month, but 
then cease to be functionally equivalent. That knowledge isn't available 
by lexical comparison (of course not), but it's also not available by 
dereferencing.

Regards,    Martin.

---

From: Juha Hakala <[email-masked]>
Date: Tue, 16 Jul 2013 14:59:02 +0300

Hello,

On 16.7.2013 13:19, "Martin J. Dürst" wrote:
> (that may not be a terribly good example, but I hope it's good enough 
> to show the point).

All kinds of examples can of course be made, both in favour or against 
the usage of functional equivalence. But the value of these examples is 
dependent on how much they have to do with the real life.

I hope that nobody is assigning URNs or other persistent identifiers to 
anything so ephemeral as the last issue of a journal. Libraries and 
publishers certainly don't; we use ISSNs for serial publications and 
DOIs, URN:NBNs etc. to the journal issues and articles. If an article 
has both DOI and URN:NBN these two identifiers are and will remain 
functionally equivalent.

There are cases when it is necessary to keep track on & provide access 
to updated versions of a resource. W3C approach is to make the latest 
version available in the same address, such as 
http://www.w3.org/TR/rdf-syntax-grammar/ for the latest version of 
RDF/XML syntax specification. Library approach would be to assign 
persistent URN to the immaterial work, and then link the different 
manifestations and versions of the work to the work level metadata 
record. Our manifestation identifier oriented URN namespaces such as 
ISBN or NBN do not allow the practice of re-using the same identifier 
for successive versions of the same resource.

All the best,

Juha
>
> For a journal that's published every month, a specific individual 
> issue and the 'last issue' will be "functionally equivalent" for a 
> month, but then cease to be functionally equivalent. That knowledge 
> isn't available by lexical comparison (of course not), but it's also 
> not available by dereferencing.

-- 

  Juha Hakala
  Senior advisor

---

From: SM <[email-masked]>
Date: Tue, 16 Jul 2013 10:18:24 -0700

Hu Juha, Peter,
At 23:09 15-07-2013, Juha Hakala wrote:
>This assumes that there are no applications which have full 
>knowledge or control of resources. Applications in which persistent 
>identifiers will be used, such as digital preservation systems and 
>web archives, may not have "full knowledge or control" (whatever 
>that means). However, it is a normal practice in these applications 
>to calculate a checksum for all ingested documents in order to find 
>out if a copy of the resource is already stored in the system. If a 
>duplicate is found, and if the stored copy has another URN, then the 
>system will know that these two URNs are functionally equivalent.
>>For this reason,
>There is nothing application dependent in checking with e.g. MD5 if 
>two files are identical.

It seems to me that you are looking at the problem from different 
angles.  I would describe it as conceptual differences instead of 
differences about terminology.  It might be about trying to fit URNs 
into what the IETF is familiar with versus having a common 
understanding of URNs and then work things out from there.

Regards,
-sm

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Jul 2013 12:31:07 -0600

On 7/16/13 11:18 AM, SM wrote:
>> This assumes that there are no applications which have full knowledge
>> or control of resources. Applications in which persistent identifiers
>> will be used, such as digital preservation systems and web archives,
>> may not have "full knowledge or control" (whatever that means).
>> However, it is a normal practice in these applications to calculate a
>> checksum for all ingested documents in order to find out if a copy of
>> the resource is already stored in the system. If a duplicate is found,
>> and if the stored copy has another URN, then the system will know that
>> these two URNs are functionally equivalent.
>>> For this reason,
> into what the IETF is familiar with versus having a common understanding
> of URNs and then work things out from there.

Hi SM,

That may be. My point is that if application developers wish to go
searching for functional equivalence, they are free to do so. However,
we don't need to say anything about that in 2141bis, just as RFC 3986
didn't try to define the possible ways to determine functional
equivalence for URIs in general. What would be the purpose of this text?
What would break if we don't include it? Remember, 2141bis is about URN
syntax, and it seems to me that syntactically all we can talk about is
lexical equivalence.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Jul 2013 12:34:02 -0600

> syntax, and it seems to me that syntactically all we can talk about is

Indeed, I would go farther and assert that we don't need the current
text on functional equivalence (Section 7) -- what's said in RFC 3986 is
enough and we cite that normatively.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: SM <[email-masked]>
Date: Tue, 16 Jul 2013 13:52:26 -0700

Hi Peter,
>enough and we cite that normatively.

I'll apologize beforehand for the IETF perspective of my comment.

RFC 3986 is already cited normatively.  The draft can avoid getting 
into that.  The developer still has the ability to go and search for 
equivalence if he or she wishes.  I think that the angle to look into 
is what would break if we don't include the text.  If I read Juha's 
message correctly it does not break anything.

Regards,
-sm

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Jul 2013 15:08:55 -0600

On 7/16/13 2:52 PM, SM wrote:
> Hi Peter, At 11:34 16-07-2013, Peter Saint-Andre wrote:
>>> That may be. My point is that if application developers wish to
>>> go searching for functional equivalence, they are free to do
>>> so. However, we don't need to say anything about that in
>>> 2141bis, just as RFC 3986 didn't try to define the possible
>>> ways to determine functional equivalence for URIs in general.
>>> What would be the purpose of this
>> text?
>>> What would break if we don't include it? Remember, 2141bis is
>>> about URN syntax, and it seems to me that syntactically all we
>>> can talk about is lexical equivalence.
>> 
>> Indeed, I would go farther and assert that we don't need the
>> current text on functional equivalence (Section 7) -- what's said
>> in RFC 3986 is enough and we cite that normatively.
> 
> into that.  The developer still has the ability to go and search
> for equivalence if he or she wishes.  I think that the angle to
> look into is what would break if we don't include the text.  If I
> read Juha's message correctly it does not break anything.

I'd agree.

My philosophy of spec-writing has always been, if it's not mentioned
in the spec then you are free to do something interesting and creative
to solve whatever problems you need to solve in the real world.
Searching for functional equivalence seems to be one of those cases.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Juha Hakala <[email-masked]>
Date: Wed, 17 Jul 2013 07:57:06 +0300

Hello Peter & SM,

It is fine with me if we do not include functional equivalence in 
rfc2141 at all. Then we can streamline the lexical equivalence chapter 
by dropping "lexical" and referring to RFC 3986 whenever possible.

There are other, more appropriate places to deal with functional 
equivalence. IETF or other bodies may consider publishing guidelines for 
URN assignment & resolution. These documents can make the point that a 
single resource may receive multiple URNs and describe means for 
determining if this is the case (that is, if URNs are functionally 
equivalent). Or, perhaps we can say in rfc3406bis that the URN 
namespaces are not and do not need to be mutually exclusive.

Juha

On 17.7.2013 0:08, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJR5bZmAAoJEOoGpJErxa2pK5UP/1u1dLJuHmp/AzDWWGqd803a
> G9qX6MPBDfDss6LSpfuJzttszhg0pByvH0X2vaYUeasVZ8pYt7TVO8x9l4xT3qDn
> 9kO0K1dVmGXP0bTY/SBCrEtycLTR7Zz7MVZP7y/FDIK2TGoMjZvd0dd11SKT62rL
> m2PsJh/14LcwUBkgnAt8H9ozIPDMbMH9al7oDN/+0gIk6nRM+TsLm+N0+NOc/Y2n
> jJodeC8U+YgptlthSXUHnE5crmls54Xvpbhtl+Md6bx5M5lcV+ATvIe+82X80KPJ
> nhJoqg0H84vBILz63urwyiN1eNDWFq98XQ6KM7AZmIX4IaaXbgOAaxz8OHv9k+cZ
> uOYZUdYeq5dBfER4OiAM3TeU1Hu9qthNJ9PpWQ6TCJM/1QDulpZ7DRARUXKR6hLO
> MzlDyBBvr7UCVf0BpVZ2GrqMwkKUURWJxP6PW89c7asiY1If6yvaLFzjq8avO75/
> 4mZZjB4ZUKitsMdtZpLYjwqlIGqLUWcG6xnwWRHiemWu6mHuAsBNE+fliMTx11Uj
> obsGNarsf0mS8H/u4GMDeiiwTG2b4upQB9hV8BiBRbqm8QuJr7oLQVzSnfdm7HDW
> G591OJtNV4xS5B2uJzw4mcQFzghTQN/vhbaTuStkJMn6SMcX0dQ5RXCp8NFdlH38
> MYoDpyQzd21BS44P/qto
> =DdoR
> -----END PGP SIGNATURE-----

-- 

  Juha Hakala
  Senior advisor

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Jul 2013 22:21:57 -0600

> by dropping "lexical" and referring to RFC 3986 whenever possible.

That sounds like an ideal approach. Thanks for your flexibility.

> namespaces are not and do not need to be mutually exclusive.

I shall look at 3406bis more closely to see if there is a good place to
mention that topic.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Jul 2013 17:16:05 -0600

> I shall look at 3406bis more closely to see if there is a good place to

Section 5.1.2 of 3406bis currently says:

   It is expected that more than one namespace might serve the same
   "functional" purpose; the intent of the "Namespace Considerations"
   section is to provide a record of the proposer's "due diligence" in
   exploring existing possibilities, for the consideration by the
   Internet community, expert reviewers, and the IESG.

We could expand the first clause a bit. Here is proposed text:

   URN namespaces are not mutually exclusive, and it is expected that
   in certain circumstances URNs from different namespaces might serve
   the same "functional" goal or identify the same resource (e.g.,
   URNs from different namespaces might be assigned to the same
   resource for purposes that differ in scope or intent).  The
   objective of the "Namespace Considerations" section is to provide a
   record of the proposer's "due diligence" in exploring existing
   possibilities, for the consideration by the Internet community,
   expert reviewers, and the IESG.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 24 Jul 2013 14:06:49 +0900

Looks good to me.   Regards,   Martin.

On 2013/07/24 8:16, Peter Saint-Andre wrote:
>>> Hello Peter&  SM,
>>> URN assignment&  resolution. These documents can make the point that a

---

From: SM <[email-masked]>
Date: Tue, 23 Jul 2013 22:28:34 -0700

Hi Peter,
>    expert reviewers, and the IESG.

The proposed text looks ok.

Regards,
-sm