Subject: Re: [urn] URN standard

From: John C Klensin <[email-masked]>
Date: Fri, 05 Jun 2015 14:41:50 -0400

Sorry... sent from wrong address.

--On Thursday, June 04, 2015 08:24 -0400 Keith Moore
<[email-masked]> wrote:

> IMO we should declare URIs (whether or not persistent) that
> don't begin with "urn:", or which do begin with "urn:" but
> don't use registered namespaces, as out-of-scope. 

I think we have done the latter.  Indeed, I think we've don't
something more strongly by declaring them invalid.  That
assertion is part of note about experimental namespaces in
Section 6, but could be moved to a more prominent place and
strengthened if someone thought it necessary and suggested text
and a place to put it.  

With regard to other URIs, I don't think there is anything in
any of our documents that suggests they are within scope.  If
you are aware of exceptions, please point them out.  On the
other hand, as far as our discussions are concerned, the WG's
declining to adopt the "URNs are not URIs" approach makes a
certain amount of discussion of the relationship inevitable much
as I'd like to minimize it.

>...
>>   * A much narrower concept, involving URNs linked to a
>> 	DDDS-based resolver directory.
> 
> This is another thing that I need to check, but my
> recollection is that we never intended for DDDS to be "the"
> sole resolver directory - it was only an example of a way to
> find resolvers.   More broadly, URNs are still valid even if
> they can't be resolved, and whether a particular URN can be
> resolved is something that can change (in either direction)
> over time.   So I don't find the "DDDS-resolvable URN" concept
> to be terribly useful.

I certainly agree and Michael's note certainly reinforces that
view.  However, I continue to see a logical problem in that
either the same resolution mechanism or resolver-finding
mechanism is applicable to all URNs (which we agree is not the
case and should not be) or resolver-finding is per-namespace.
I think you have strongly objected to the latter, so I'm not
sure where you think we should go or what words should go into
2141bis.

>...
> The first step in an engineering exercise is supposed to be to
> define the problem.    It seems to me that the problem
> definition for URNs was never really stated to a sufficient
> degree, and that some want to dismiss or change the part of
> the definition that was stated.   Then when there's some
> disagreement about some aspect of what we're trying to do, we
> don't have any agreed-on problem definition to refer to in
> order to evaluate competing ideas.   So some people want to
> refer to 1737, and others want to ignore it. Some people want
> to cite the spectrum of existing usage of URNs as the problem
> definition, even though those are not representative of the
> problem that we were trying to solve in the original URI/URN
> WGs.   And some of us who were actively participating way back
> when want to rely on the shared concept that we believed many
> of us had arrived at (through years of hard work) even if some
> of that concept wasn't ever captured in a document.  etc.

Suppose I agree with that as a statement of the meta-problem if
not the problem (personally, I'm coming to a much more general
conclusion, but it isn't helpful).  How do you think we should
proceed from it?  Presumably, mourning our fate and the bad
situation we are in is not particularly helpful in moving
forward.

> I'm fine with deferring that set of issues except when we
> start setting bad precedents or going in a direction that
> breaks something important.     But again, it's hard to argue
> that a precedent is bad, or that something important is being
> broken, without a problem definition to refer to.

Agreed.  But, if you don't believe we have an adequate problem
definition on which to proceed, we either have to face the
question about the meta-problem above, or we are at dead stop
until we fire up and complete a problem definition process.    I
don't see any energy for that.  Even if I did, I think it would
be no more likely to completely converge and reach consensus
than we were nearly 20 years ago.    

I really hate being in a situation in which the best way we can
characterize a collection that is (or is not) suitable for a URN
namespace is on the basis of "I know one when I see one" or,
perhaps better, "Keith, Leslie, and/or Michael know one when
they see one".  However, if that is where history has left us
and the notion of starting over with new definitions of the
problem (and of "persistence", etc.) is as implausible and
impractical as I think it is, then shouldn't we be concentrating
on how to move forward and, in particular what text should be
added to or changed in 2141bis?

    john

---

From: Keith Moore <[email-masked]>
Date: Sat, 06 Jun 2015 00:34:07 -0400

On 06/05/2015 02:41 PM, John C Klensin wrote:
> any of our documents that suggests they are within scope.

Ok, good.  That was my impression also, but something you said made me 
wonder if maybe we weren't on the same page about that.

> On the

I guess that depends on whether one believes that we have to somehow 
reconcile RFC 3986's idea that there are URNs that don't begin with 
"urn:", with common sense.   But as of the last time I read 2141bis in 
its entirety (which I need to do again), the language in that document 
regarding what was in scope seemed ok to me.

> sure where you think we should go or what words should go into

Slightly different wordings can mean very different things.

If a client is looking for a namespace-authorized resolution service via 
a DDDS-like service, yes, that's inherently a per-namespace lookup.
However, clients should also be able to consult non-authorized 
resolution services.   Such services won't be inherently federated by 
URN namespace.

(Note that a "resolution service" is really nothing but a database that 
can be queried using one of a hopefully-small number of known resolution 
protocols.   To me, saying that all resolution services have to be 
namespace-authorized and federated by namespace seems tantamount to 
saying that nobody besides a namespace can operate a service that 
permits queries by URN.   And this seems to be assigning a much greater 
role to the namespace than was anticipated in any of the existing URN RFCs.)

> situation we are in is not particularly helpful in moving

I agree that mourning is pointless, at least within the context of this 
WG's discussion.    (Learning from this WG's experience might be useful, 
but probably not in this context.)

One way forward would be to try to agree on a problem definition. I 
don't really recommend that, because a lot of people are already tired 
of trying to present their view of the problem.

Another way forward would be to rely on RFC 1737, imperfect though it 
is.    Even if we were comfortable with that approach, I suspect it 
would still leave some loose ends.   Regardless of what one thinks about 
RFC 1737, the original URN WG was directed by its charter to comply with 
it, and presumably did so. 
https://datatracker.ietf.org/wg/urn/charter/   So I think it's fair to 
cite 1737 as at least part of a problem definition of URNs.   And even 
if one has reservations about RFC 1737, it is nowhere nearly as bad as 
RFC 3986 is, and we seem to have found a way forward in spite of the latter.

Another way is to do what IETF normally does:  Skip trying to define the 
problem and just try to get consensus on a solution to a problem even 
though people might not actually have consensus on what the problem is 
(*).   This might be the most expedient thing to do. However, it comes 
with a risk, which is that if anyone tries to raise an objection on 
technical grounds, IESG and higher-ups don't really have much in the way 
of criteria to evaluate the objection.    And even if this WG has 
complete agreement, I suspect there's a better-than-even chance of 
someone objecting at Last Call, just because of the amount of religion 
around URNs that's out there.

But if we can get consensus on 2141bis without trying to sort out the 
URN problem definition again, that's probably the most expedient thing 
to do for now.   It just needs to be a strong consensus within the WG.

(*) it's tempting to try to explain why this ever works for IETF at all, 
but it would probably be a distraction.
> they see one".

I don't like it either, but even recent discussions within this WG, as 
well as with its chairs and ADs, convince me that it's an accurate 
assessment of the situation.

I think it should be fixed, but I'd like to try to finish 2141bis before 
we try to fix it.     (Though it would surely be odd if the ADs were to 
recharter this WG to define the URN problem as its last work item.)

>   However, if that is where history has left us

I really don't think we should revisit the definition of "persistence" 
because as far as I can tell, the text in 1737 is highly unlikely to be 
improved upon, at least within an IETF WG discussion.
(If we were to have a problem definition discussion, we might do well to 
rule certain questions already-settled and therefore out-of-scope.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 06 Jun 2015 00:47:21 -0400

> assessment of the situation.

I realized after hitting "Send" that I misspoke (miswrote?) above.

My assessment of the situation is /not/ that "Keith, Leslie, and/or 
Michael know one when they see one". It's that we lack an agreed-on 
problem definition, and that the lack of an agreed-on problem definition 
is one of the primary reasons why we so often dig ratholes and/or 
alienate participants.

(now I hope to make another review pass over 2141bis before needing to 
reply again.)

Keith

---

From: Michael Mealling <[email-masked]>
Date: Mon, 8 Jun 2015 10:27:46 -0400

This is my characterization that I thought had made it into some of the discussions but apparently never made it into a document as axiomatic. 

Its not that a URN is suitable if "Keith, Leslie, or Michael say so when they see it", its that someone asserts that they are following the rules as specified in the registration documents. If someone asserts in the NID registration that they are following the rules of non-reassignment, syntax, etc then everyone can assume those rules are being followed. If they come across a situation in which they aren't they get to then assume that the namespace maintainer made an error, not that that the consumer made an error. 

So anything can be a URN IFF you agree to the limited set of requirements in 2141 and the registration documents. If you then break your agreement everyone knows you are the source of the problem. This solves the problem of not knowing if

http://example.com/weather/today.html

is the same thing today as it is tomorrow. An HTTP URI doesn't tell me anything about that. I could retrieve today's weather from that URI and make some guesses based on some assertions about caching in the HTTP headers but if I retrieve it the next day and get back a news story about Siberian coal mining I have no idea whether the owner of example.com intends for those two things to be the same or not.

But, if they register the 'example' URN NID then they are making an explicit statement that I can rely on that "urn:example:weather:today" is always the same Resource no matter when I resolve it. If I resolve that URN authoritatively and get back todays weather today and a Siberian coal mining story the next day I can reliably assume that this URN is saying those two things are the same Resource. I may not think so but at least I can safely rely on the NID registration process assuring me that THEY think it is. 

In the HTTP URI example, making assumptions is an error on my part.

In the URN example, breaking my assumptions is an error on their part. 

IMHO, reliable assumptions about what things are today vs tomorrow is what URNs were all about and the basis of building temporarily reliable systems.

-MM

> On Jun 6, 2015, at 12:34 AM, Keith Moore <[email-masked]> wrote:
> I don't like it either, but even recent discussions within this WG, as well as with its chairs and ADs, convince me that it's an accurate assessment of the situation.
> 
> I think it should be fixed, but I'd like to try to finish 2141bis before we try to fix it.     (Though it would surely be odd if the ADs were to recharter this WG to define the URN problem as its last work item.)

---

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 10 Jun 2015 10:46:26 +0000

Hello, 

Comments below. 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Michael Mealling
> Sent: 8. kesäkuuta 2015 17:28
> To: Keith Moore
> Cc: [email-masked]
> Subject: Re: [urn] URN standard
> 
> Its not that a URN is suitable if "Keith, Leslie, or Michael say so when they see
> it", its that someone asserts that they are following the rules as specified in
> the registration documents. If someone asserts in the NID registration that
> they are following the rules of non-reassignment, syntax, etc then everyone
> can assume those rules are being followed. If they come across a situation in
> which they aren't they get to then assume that the namespace maintainer
> made an error, not that that the consumer made an error.

Almost every URN namespace says something about the syntax of NSS. But well defined URN namespaces should also have rules concerning semantics (scope) of the identifier. NID registration may provide only a summary of this. For instance, URN:ISBN namespace registration is not as exhaustive as the ISBN Users' Manual.  IMO namespace registration should provide a link (preferably a persistent one) to this kind of external information. This way the scope description does not need to be repeated in the NID registration. 

Any identifier which has a generic scope such as Handle, DOI or URN:NBN (and of course URN:UUID) is difficult to manage well and does not function properly unless the people who assign these identifiers know what they are doing.  Well managed namespaces like URN:ISBN are less demanding in this respect because there are usually written rules which to follow.  

> So anything can be a URN IFF you agree to the limited set of requirements in
> 2141 and the registration documents. If you then break your agreement
> everyone knows you are the source of the problem. This solves the problem
> of not knowing if
> 
> is the same thing today as it is tomorrow. An HTTP URI doesn't tell me anything
> about that. I could retrieve today's weather from that URI and make some
> guesses based on some assertions about caching in the HTTP headers but if I
> retrieve it the next day and get back a news story about Siberian coal mining I
> have no idea whether the owner of example.com intends for those two things
> to be the same or not.

For URLs it is safe to assume that the content of the page may not the same anymore, just like it is safe to assume that after e.g. 5 years a book in a library may not be found from the same shelf location. The difference is that in the library a user can tell that the book has changed; in the Web that may not be obvious. 
  
> But, if they register the 'example' URN NID then they are making an explicit
> statement that I can rely on that "urn:example:weather:today" is always the
> same Resource no matter when I resolve it. If I resolve that URN
> authoritatively and get back todays weather today and a Siberian coal mining
> story the next day I can reliably assume that this URN is saying those two things
> are the same Resource. I may not think so but at least I can safely rely on the
> NID registration process assuring me that THEY think it is.

Yes, I can imagine a namespace where those documents are just two aspects of a single identified work, shown one after another. 

> In the HTTP URI example, making assumptions is an error on my part.

... but you could put a blame on those who've told you that URIs are cool ;-). 
 
> In the URN example, breaking my assumptions is an error on their part.

... provided that you have formed your expectations correctly on the basis of the NID registration and additional information available (if any). 

Of course, in the very long run (centuries, even) only those URNs and other PIDs which are well managed will remain resolvable. Stable organizations such as national libraries and national archives have the best chances of succeeding in this task. Of course it is going to be a major challenge, but it has to be done. We must not allow for instance links to electronic resources in scientific articles to "die".  

Juha

> IMHO, reliable assumptions about what things are today vs tomorrow is what
> URNs were all about and the basis of building temporarily reliable systems.
> 
> -MM
> 
> 
> >> namespace is on the basis of "I know one when I see one" or, perhaps
> >> better, "Keith, Leslie, and/or Michael know one when they see one".
> >
> > I don't like it either, but even recent discussions within this WG, as well as
> with its chairs and ADs, convince me that it's an accurate assessment of the
> situation.
> >
> > I think it should be fixed, but I'd like to try to finish 2141bis before we try to
> fix it.     (Though it would surely be odd if the ADs were to recharter this WG
> to define the URN problem as its last work item.)
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn