Subject: [urn] urn:ietf:rfc (was: [Tools-discuss] xml.resource.org is down)

From: SM <[email-masked]>
Date: Thu, 22 May 2014 08:50:12 -0700

Hi Michael,

[Cc to URNbis and Barry as he wrote RFC 6924]

At 06:35 22-05-2014, Michael Richardson wrote:
>I'm saying that we (the IETF) have totally failed to dogfood URNs.

Ok.

>It seems that there are tragedy-of-the-commons for much of the URN stuff,
>and it seems that this is more than a nobody-is-running-the urn:ietf: server,
>because there is, I think, client-side stuff that has to happen, and maybe
>there is a lack of client side code.

urn:ietf:rfc has been registered.  What needs to be done to fix the 
resolution of the namespace?

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Thu, 22 May 2014 12:09:11 -0400

> resolution of the namespace?

I don't understand:
URNs are names, not locators.  They aren't meant to be "resolvable" in
the sense that, say, an http URI is.

"urn:ietf:rfc:6924" is a name for RFC 6924, which uniquely and
persistently identifies it.

The following are all locators that will find the document that URN names:

http://datatracker.ietf.org/doc/rfc6924/
http://tools.ietf.org/html/rfc6924
http://tools.ietf.org/rfc/rfc6924.txt
http://tools.ietf.org/pdf/rfc6924
http://www.rfc-editor.org/rfc/rfc6924.txt
http://www.rfc-editor.org/pdfrfc/rfc6924.txt.pdf

How you *find* documents, given their names, is well out of the scope
of naming them.

Barry

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 May 2014 18:09:54 +0200

> resolution of the namespace?

What problem are we solving by having a resolver for these URNs?

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 May 2014 12:42:18 -0400

--On Thursday, 22 May, 2014 12:09 -0400 Barry Leiba
<[email-masked]> wrote:

>>> It seems that there are tragedy-of-the-commons for much of
>>> the URN stuff, and it seems that this is more than a
>>> nobody-is-running-the urn:ietf: server,
>>> because there is, I think, client-side stuff that has to
>>> happen, and maybe there is a lack of client side code.
>> 
>> urn:ietf:rfc has been registered.  What needs to be done to
>> fix the resolution of the namespace?
> 
> I don't understand:
> URNs are names, not locators.  They aren't meant to be
> "resolvable" in the sense that, say, an http URI is.
> 
> How you *find* documents, given their names, is well out of
> the scope of naming them.

Barry,

Fortunately or unfortunately, the interplay between assorted
URN, URI, and DDDS documents provides a solid basis for claiming
that URNs can be bound to resolution services as well as just
names.  So, without looking up the NID spec for urn:ietf:rfc, it
could either be "just a name" or be bound to a resolution
service that would, in turn, be able to provide a locator
associated with that name.  So, although it should have been
stated differently if one being very precise, SM's question is
reasonable.

That interplay and its non-obvious side effects are another
reason for separating URNs from the URI family, thereby
requiring that any words about resolution services be explicit
in 2141bis and/or the 3406bis discussion and template rather
than requiring a treasure hunt of a variety that caused you, SM,
and Julian to make slightly different inferences about what was
(or should be) going on.

The URIs are not URNs draft does not deal with that particular
issue explicitly in the current version and probably should.

    john

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 May 2014 19:10:59 +0200

On 22 May 2014, at 18:09, Barry Leiba <[email-masked]> wrote:

> […]

Actually, for RFC production we are interested in metadata about this RFC, as we would find it in

	http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6924.xml

(Note that the transformation from the URN to this URL is non-trivial, and currently encoded in some ad-hoc code at various places.)

I think I’d like to see something like

	http://metadata.ietf.org/urn:ietf:rfc:6924

at some future point in time.

Bonus points if something like this also works for

	http://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.REC-html401-19991224.xml

etc.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 May 2014 13:26:58 -0400

On Thursday, 22 May, 2014 12:09 -0400 Barry Leiba <[email-masked]> wrote:
barry> URNs are names, not locators.  They aren't meant to be
barry> "resolvable" in the sense that, say, an http URI is.

agreed, and this is why they are so useful a thing to put into
your .xml document;  I don't care where the data comes from,
I just want it, and if it can come from my local hard disk, even better...

barry> How you *find* documents, given their names, is well out of
barry> the scope of naming them.

    > stated differently if one being very precise, SM's question is

I know that there are mechanisms... (reads... ) rfc3401, etc.
which would let one map urn:ietf to something which might be
widely mirrored.
Why aren't we using them?

I think it is because:
  1) no client code which xml2rfc could easly leverage.
  2) nobody is running the right urn.arpa. DNS system for it,
  and the system(s) it would point to.  Possibly because the software
  to serve that does not exist.  (I don't know. I suspect it's just
  DNS, but, I didn't read past abstracts...)

i.e. lack of running code.  Maybe there is code, but maybe it's not
     deployed.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 May 2014 14:11:41 -0400

--On Thursday, 22 May, 2014 19:10 +0200 Carsten Bormann
<[email-masked]> wrote:

>> The following are all locators that will find the document
>> that URN names: […]
> 
> 
>...

Folks, for those who are actually interested in URN rather than
using this list to complain about a perceived IETF operational
problem, this actually illustrates a point that Juha (and, to
some extent, myself) have been trying to make.

   urn:ietf:rfc:6924

is, as Barry says, a name for RFC 6924, an object that, as far
as the URN specs are concerned, and that, in principle, may or
may not be retrievable over the Internet.    RFC 6925 may have
other names.  It may have a location.  And it may have
descriptive information such as a bibliography entry.  The
latter may, in turn, be available in multiple forms: RFC plain
text, ALS, bibtex, xml2rfc, etc.

Similarly a hypothetical 
   urn:duck:johns-duck-33
may be a name with no other properties or at may be associated
with a location algorithm or locator (probably a different type
than an RFC), and assorted additional information that one might
want without wanting the duck itself: length, weight, age, color
scheme, whether it quacks when squeezed, whether it is a live
duck, a recently-alive duck, or a rubber ducky, etc.  I'm pretty
sure that it won't have bibliographic information, but one can
never know for sure (e.g., there is no International Standard
Duck Number, at least as far as I know).

Those properties -- what information is available about the
URN-named object and how that information is identified -- have
to be part of NID registration (perhaps by reference).  Unless
we aspire to a Universal Digital and Non-Digital Description
Language (if anyone does, enjoy yourself and please arrange for
a report to the IETF when you emerge victorious from the rat
hole), there is simply no other place to put it.

But, even for RFCs, Michael wants to get the document associated
with the urn:ietf:rfc:6924 name (or a locator for it) and
Carsten wants a bibliographic entry in a particular format (or a
locator for that).  That is at least five separate cases for a
relatively simple case:

  name-in-itself
  copy of RFC wanted
  locator for RFC wanted (one or several- another distinction)
  copy of xml2rfc-formatted bibliographic entry
  locator for that entry

That implies that you can't just say 
   urn:ietf:rfc:6924

because, at least absent information in the NID registration,
that is just the name.  One decision we need to make is whether
it should _always_ be just the name because 2141 is less than
clear as illustrated by earlier messages in this thread.

But, if you want that other stuff, you have to be able to
specify which stuff you are looking for.  2141 syntax is simply
not adequate.  One could extend it with the query syntax of RFC
3986 but it is not clear whether the implicit semantics for URI
queries are really appropriate to a "this is the information
associated with that name which I need" specification,
especially if there are NIDs that also need things more similar
to a traditional query (such as something that should be passed,
intact, to a locator.  If both need to be specified, we either
end up violating or overconstraining 3986, or we develop
something complex and nested that will turn URNs (and us) into a
joke, or a take a URN path that is different from the Generic
URI one.   

That is precisely what the "URNs are not URIs" effort is about.

     john

---

From: Michael Mealling <[email-masked]>
Date: Thu, 22 May 2014 14:26:58 -0400

>  DNS, but, I didn't read past abstracts...)

All modern DNS servers support the required records so someone just needs to specify what the records hold and put them into the zone. Several such records already exist...

-MM

Michael Mealling
Co-Founder
Pipefish.com
+1-678-640-6884	@mmealling
Schedule a meeting:  http://meetme.so/michaelmealling

---

From: SM <[email-masked]>
Date: Thu, 22 May 2014 14:49:54 -0700

Hi Barry, John, Julian,
>the sense that, say, an http URI is.

Agreed.

>persistently identifies it.

The short answer is yes.

>How you *find* documents, given their names, is well out of the scope

The discussion (on other IETF mailing lists) was about having a 
mechanism to resolve the name.

>stated differently if one being very precise, SM's question is

Apologies for the ambiguous question.

Yes, what I was thinking about is passing "urn:ietf:rfc:6924" to a 
resolution service which would provide a locator.  The locator can 
change in future.  That does not affect the name.

>What problem are we solving by having a resolver for these URNs?

The problem is how do I use "urn:ietf:rfc:6924"?  For example, can I 
use "urn:ietf:rfc:6924" instead of http://www.rfc-editor.org/rfc/rfc6924.txt?

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Thu, 22 May 2014 18:00:58 -0400

> The problem is how do I use "urn:ietf:rfc:6924"?  For example, can I use
> "urn:ietf:rfc:6924" instead of http://www.rfc-editor.org/rfc/rfc6924.txt?

The answer depends upon what you want to use it for.  Mostly, the
thing that uses it has to know how to resolve it.

So, for instance, if xml2rfc were to accept the RFC (and ID, and BCP,
and STD) URNs, then it could turn them into proper references, which
is what xml2rfc needs them for.

Putting the URN into the search field of the datatracker would have a
different result, but one that's equally useful in that context.

Barry

---

From: SM <[email-masked]>
Date: Thu, 22 May 2014 15:36:07 -0700

Hi Barry,
>different result, but one that's equally useful in that context.

My understanding of the above is:

   (i)  I can use a name in various ways.

   (ii) The result is dependent on the resolution process.

One issue, unrelated to (i) and (ii), is that the name (urn:ietf:rfc 
...) does not identify one thing.  I can get a RFC as .txt or .pdf 
(different formats) or I can get metadata about the RFC.

Regards,
-sm

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 May 2014 16:47:34 -0600

On 5/22/14, 4:00 PM, Barry Leiba wrote:
>> The problem is how do I use "urn:ietf:rfc:6924"?
>
> The answer depends upon what you want to use it for.

Just FYI, in the XMPP world, we have an example of one way to use it. In 
our specification of the ICE-UDP transport method in our Jingle 
technology for establishing media sessions, we use "urn:ietf:rfc:3264" 
as an identifier for offer/answer mode (i.e., not trickle-ICE), which is 
defined in RFC 3264...

http://xmpp.org/extensions/xep-0176.html#support-sdp

That is, we're referring to "the feature defined in RFC 3264", and we 
don't care about the physical location of the specification itself.

But I realize that's not what folks are trying to do in the thread that 
SM mentioned.

Peter

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 May 2014 18:58:34 -0400

--On Thursday, 22 May, 2014 15:36 -0700 SM <[email-masked]>
wrote:

> One issue, unrelated to (i) and (ii), is that the name
> (urn:ietf:rfc ...) does not identify one thing.  I can get a
> RFC as .txt or .pdf (different formats) or I can get metadata
> about the RFC.

I try to use the term "metadata" in these discussions because
the term has been so much overused in different ways that it has
become a synonym for "hand waving".  But the above can
reasonably include

* a bibliographic reference to the RFC (potentially in different
forms)
* a question about the forms in which the bibliographic
reference can be obtained
* locators for at least the first of these and maybe the second.
   --plus--
* the RFC in various forms
* locators for those forms
* a question about what forms are available.

Note that some of these are requests for the object, others are
requests for information about how to find the object, and still
others are requests for specific information about the object
(possibly with additional indirection).

Any or all of them can be associated with the name and what is
very loosely called a resolution service -- loosely because some
of the above might ultimately call for different resolution
services, possibly redirected through the initial one.  In
particular, if one can figure out what "metadata" means in terms
of its differentiating properties, the resolution service for
the object and the resolution service for object metadata might
be different.  And _that_ is another reason why some of us are
concerned about the limitations of the Generic URI syntax.

For a specific URN type (NID) all of the above must be bound to
the NID registration/definition itself in some way unless we
want to go into the universal data dictionary business.

See my recent, longer, note for a slightly different take on
this.

     john

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 May 2014 19:40:14 -0400

(Changing subject line, which should have been done some time
ago-- this really isn't about RFC URNs except as a handy example)

--On Thursday, 22 May, 2014 16:47 -0600 Peter Saint-Andre
<[email-masked]> wrote:

> Just FYI, in the XMPP world, we have an example of one way to
> use it. In our specification of the ICE-UDP transport method
> in our Jingle technology for establishing media sessions, we
> use "urn:ietf:rfc:3264" as an identifier for offer/answer mode
> (i.e., not trickle-ICE), which is defined in RFC 3264...
> 
> That is, we're referring to "the feature defined in RFC 3264",
> and we don't care about the physical location of the
> specification itself.
> 
> But I realize that's not what folks are trying to do in the
> thread that SM mentioned.

Actually, Peter, this is very helpful because it illustrates
why, at least IMO, Barry and those folks aren't communicating.

There are three ways to get from a URN to one of more resolution
services (for those URNs that need or have such services and
whatever, generically, that means).  One is to bind the set of
things that can be produced by a resolution process to the
resolution mechanisms in using protocol definition itself.  That
is what you describe above.  If an XMPP application encounters
an urn:ietf:rfc URN, it uses that information as an indicator
and doesn't, in the traditional sense, resolve it at all.

A second is to bind to an actual resolution mechanism (or
task-specific set of them) in the NID definition or something it
points to, so that definition would say "if you want the RFC
text in PDF form, construct a URL as follows" and "if you want
an XML2RFC bibliographic reference for the RFC, construct a
URL..." and so on, for a long list.  That list might or might
not include a note about how XMPP uses the URN, e.g., "name only
as indicator".   For those old enough to remember, if we still
had "How to obtain RFCs" around and considered it normative, the
NID definition might incorporate it by reference for some of
that information.

Or, in the grand tradition of Computer Science and Internet
Engineering, one could introduce another layer of indirection.
One might want to do that for many reasons, but one would be
that elements of the resolution-location process might not be
stable.  RFCs are not a particularly good example because, if
rfc-editor.org and ietf.org aren't around and willing to keep
the links stable, maybe no one else cares.  Or not.  But suppose
we had a universal dodo identifier based on the International
Dodo Registry:

   urn:dodo:32

Now that raises all of the issues a few of us have been
discussing.   The URN itself provides information: Dodo 32 is
presumably a different dodo than Dodo 47.   But one can want to
locate or obtain Dodo 32, one can want information about it,
such as its weight or state of health (probably pretty
consistent for dodos), and so on and a way is needed to talk
about that different stuff.  More important, if the Dodo
Registry were, say, at Oxford University, one might want some
level of indirection in case Oxford decided to transfer the
registry elsewhere or to close its institutional doors (this is
one place where the difference between tens of years and tens of
centuries becomes important).  Our typical way to way to deal
with that would be to build the constructed URL template as
Method://international-dodo-registry.org/?dodo-number=32> but
suppose one's concerns about permanence _for the particular NID_
was such that you wouldn't want to trust in the continued
existence of the DNS or that of the ORG TLD?  That is the job
URN.ARPA was intended to serve, so that dodo.urn.arpa would
provide a pointer to where the template information was at any
given time and/or appropriate DDDS material.  That would work
well for concerns about ORG, but not for concerns about the ARPA
TLD or the DNS.  For the latter, one would want to abstract
URN.ARPA too, such that there was a single, URN-specific (not
NID-specific) definition of where to look for the information
that is now (optionally) stored at <nid>.urn.arpa.  If the DNS
imploded, that document could be updated with the new "how to
find the tree" information and appropriate chronology retained. 

This is obviously turtles all the way down and getting the right
stopping rules requires fairly serious thought.  But, if one
wants to think about "permanence", one has to do that work...
and then the definers of each NID decide how permanent it needs
to be in terms of levels of abstraction and indirection such at
those outlined above.
    
     john

---

From: SM <[email-masked]>
Date: Thu, 22 May 2014 16:59:46 -0700

Hi John,
>concerned about the limitations of the Generic URI syntax.

A resolution service is not needed in Peter's case.  I mentioned this 
as one of different uses of a name.

I am okay with the idea of different resolution services.  One point 
in your message is the initial resolution service.  Would that be 
identified by the entity managing the namespace?

Ok.

Regards,
-sm

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 May 2014 07:53:53 +0200

>    (i)  I can use a name in various ways.

Yes.

>    (ii) The result is dependent on the resolution process.

Yes.

> (different formats) or I can get metadata about the RFC.

So assuming there *was* a resolution process for urn:ietf:rfc. How would 
it know whether you're looking for the document itself (and in which 
format), or about metadata, or a bib reference?

Concretely, how would having that resolution process solve the problem 
that started the discussion?

Best regards, Julian

---

From: SM <[email-masked]>
Date: Fri, 23 May 2014 00:20:59 -0700

Hi Julian,
At 22:53 22-05-2014, Julian Reschke wrote:
>So assuming there *was* a resolution process for urn:ietf:rfc. How 
>would it know whether you're looking for the document itself (and in 
>which format), or about metadata, or a bib reference?

The resolution process would have to be able to provide the list of 
things for the name.  It won't know what I am looking for unless the 
name identified one thing only, e.g. the bib reference.

>Concretely, how would having that resolution process solve the 
>problem that started the discussion?

The problem was about using a URN to avoid location dependence.  What 
I would need is an index and the references or a resolution process 
which takes me to a reference.  The organization managing the 
namespace could provide me with information about the resolution 
process so that I can use urn:ietf:rfc.

Regards,
-sm

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 23 May 2014 15:43:12 -0400

> From: John C Klensin <[email-masked]>

> reason for separating URNs from the URI family, [...]

> From: Michael Richardson <[email-masked]>

> i.e. lack of running code.  Maybe there is code, but maybe it's not

I think these two remarks can be extended:  As far as I can tell from
the DDDS documents, at a pont in the past it was expected (at least by
some substantial fraction of the community) that there would be an
overarching URN resolution system that would map all URN NIDs to
appropriate resolution services, and the resolution services would in
turn map the URNs into network resources (via URLs).

Clearly, this system hasn't been deployed, at least not for the
typical NID.  But its absence changes the philosophical basis of URNs:
They're still names, but it is no longer assumed that the things that
are named are network-accessible resources, which means that for many
purposes, URNs can no longer be used in locations where URLs are
needed.  Thus, the conceptual separation between URNs and URLs becomes
much larger than it was in earlier days.

One interesting question is *why* the DDDS hasn't been deployed.  It
may be impossible based on the information represented by URNs.  It
may be that there is no need to resolve most URNs.  Or it may be that
nobody has bothered implementing the software and setting up the
operational systems.  (Can't we put some graduate students on this?)

Dale

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 May 2014 16:16:50 -0400

--On Friday, 23 May, 2014 15:43 -0400 "Dale R. Worley"
<[email-masked]> wrote:

>>   and the system(s) it would point to.  Possibly because the
>>   software to serve that does not exist.  (I don't know. I
>>   suspect it's just DNS, but, I didn't read past abstracts...)
>> 
>> i.e. lack of running code.  Maybe there is code, but maybe
>> it's not deployed.
> 
> I think these two remarks can be extended:  As far as I can
> tell from the DDDS documents, at a pont in the past it was
> expected (at least by some substantial fraction of the
> community) that there would be an overarching URN resolution
> system that would map all URN NIDs to appropriate resolution
> services, and the resolution services would in turn map the
> URNs into network resources (via URLs).
> 
> typical NID.  But its absence changes the philosophical basis
> of URNs: They're still names, but it is no longer assumed that
> the things that are named are network-accessible resources,
> which means that for many purposes, URNs can no longer be used
> in locations where URLs are needed.  Thus, the conceptual
> separation between URNs and URLs becomes much larger than it
> was in earlier days.
> 
> One interesting question is *why* the DDDS hasn't been
> deployed.  It may be impossible based on the information
> represented by URNs.  It may be that there is no need to
> resolve most URNs.  Or it may be that nobody has bothered
> implementing the software and setting up the operational
> systems.  (Can't we put some graduate students on this?)

Dale,

I think this is an interesting analysis.  It stimulated an idea
I hadn't had before.

I'm pretty sure we always anticipated that some URNs would be
"pure names" --no resolution of any type anticipated, just,
maybe, comparisons.   But, even if that is right, it doesn't
change your argument very much.  Suppose we think of this whole
situation as at least partially a "levels of abstraction"
situation with

(1) locaters pointing more or less directly to network objects.
These basically involve no indirection.
(2) strings or identifiers that use a known, generic resolution
service to get to such locators.  One level of indirection.
(3) strings or identifiers that use an NID-specific resolution
mechanism (or more than one for different purposes) and that
need to specify that mechanism somewhere, perhaps through an
additional level of indirection, so there are typically one or
two levels of indirection.
(4) Pure names that aren't resolved, but might be compared
and/or used as flags or indicators.

The first group includes URLs.  Maybe everything in it is a URL.
DDDS is typical of the second and was certainly intended to be
the dominant, "standard", one.  The third is most of what my
recent note was talking about and includes such things as ISBN
and ISSN URNs.  The fourth group is pretty obvious, but we
should not forget it is out there -- and Peter's note reminds us
that that a single NID may be used, in different contexts, as
either a resolvable object (typically (3) but maybe (2)) and as
such "no resolution required or expected" names.

Especially given that breakdown, if anyone still believes that
DDDS == URN, they are pretty confused and, if participating in
this list, helping the rest of us achieve that state.   I
certainly don't read that equivalence into 2141.

Given that, I wonder whether, as a thought experiment, we should
investigate whether 
    DDDS:....
would be a useful and distinct alternative to 
    URN:nid:...

Thereby making clear that "DDDS" and "URN" are not synonyms and
separating case (2) from case (1) (the URLs) and case (3) and
(4) (the somewhat more abstracted names.   One could still have
a case (3) URN that used DDDS for some or all of its required
resolution or metadata retrieval functions, its registration
would just have to specify that.  By contrast, a name associated
with "DDDS:..." would presumably only require that the name be
registered, possibly along with a definition or explanation, but
that it was resolvable and how to do that would be
be completely obvious.

Does that help?
 best,
     john

---

From: Michael Mealling <[email-masked]>
Date: Sat, 24 May 2014 21:21:13 -0400

>> systems.  (Can't we put some graduate students on this?)

The main reason at the time was that browsers had that code locked up. This was the time of Internet Explorer's dominance and everyone pretty much gave up on implementing anything in the browser to facilitate DDDS. We (I?) essentially failed Michael Porter's Five Forces test: each case where we planned on using DDDS there was an existing player that owned a piece of the namespace that prevented deployment: the telcos defeated ENUM and the browser vendors prevented any sane extensions to the browsers. 

With the advent of a Javascript enabled browser world it would be fairly easy to implement as a JQuery plugin. 

> situation as at least partially a "levels of abstraction"

I always assumed that. Take the UUID namespace as an example. I think creating a UUID resolution service would be a fairly insane undertaking.

> certainly don't read that equivalence into 2141.

Correct. DDDS is a way of using DNS to discover syntax rules by encoding them into DNS. It has/had far more applicability in the ENUM world for decomposing telephone numbers.

-MM

Michael Mealling
Co-Founder
Pipefish.com

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 25 May 2014 19:11:05 +0900

> With the advent of a Javascript enabled browser world it would be fairly easy to implement as a JQuery plugin.

With all these many Javascript hackers around, why hasn't anybody done 
this yet?

> I always assumed that. Take the UUID namespace as an example. I think creating a UUID resolution service would be a fairly insane undertaking.

Well, in some sense there already is one. It's a combination of Google 
(or some other search engine) and probably some human intervention. But 
that's probably as good as it ever gets.
[And that's just another way to say that I agree with you that a good 
fully automatic UUID resolution service would be an insane undertaking.]

Regards,   Martin.

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 27 May 2014 15:15:31 -0400

> From: John C Klensin <[email-masked]>

> such "no resolution required or expected" names.

I think I agree with you, though I'd describe the spectrum in
different terms.  For instance, fetching a web page based on a URL
involves a tremendous amount of indirection (including not only DNS
but the routing table of every router along the path).  But in
practice, the required indirections are well-specified, and
conceptually we consider the *meaning* of the URL to be the *result*
of the resolution process (and/or the specified resolution actions
themselves).

A similar example is SIP URIs, which aren't called URLs, but have much
the same properties:  There is a rigidly specified resolution process,
and the meaning of the URI is still closely identified with the result
of the resolution process.  There is some difference, though, because
there are "address of record" URIs (like telco directory listings)
that are expected to be attached to individuals, organizations, and
the like, whose sociological meaning will change less quickly than the
identity of the SIP servers to which the URI routes.

But once we get to ISBN and ISSN, the meaning is much detached from
resolution.  In particular, there are assumed to be many different
ways of resolving the identifier (for various purposes), and no one of
them is expected to yield "the" meaning.

The extreme of this end of the spectrum are identifiers like the
urn:ietf:params URNs -- there is no particular network-accessible
resource involved, and no resolution process (in the ordinary sense)
at all.

An odd example is the Alert-Info URNs for SIP
(draft-ietf-salud-alert-info-urns), which tell phones how to announce
an incoming call (priority, internal/external source, etc.).  In that
case, there is a resolution algorithm, but it functions entirely
inside a phone, instructing how the phone should choose from among the
ringing signals that it is capable of generating which one to choose
(e.g., which information it should prioritize when it can't announce
all of the specified information).  So though the URN is tightly
identified with the resolution process, the resolution process does
not determine a network-accessible resource.

Dale

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 May 2014 15:59:21 -0400

--On Tuesday, May 27, 2014 15:15 -0400 "Dale R. Worley"
<[email-masked]> wrote:

>> (1) locaters pointing more or less directly to network
>> objects. These basically involve no indirection.
>> (2) strings or identifiers that use a known, generic
>> resolution service to get to such locators.  One level of
>> indirection. (3) strings or identifiers that use an
>> NID-specific resolution mechanism (or more than one for
>> different purposes) and that need to specify that mechanism
>> somewhere, perhaps through an additional level of
>> indirection, so there are typically one or two levels of
>> indirection.
>> The first group includes URLs.  Maybe everything in it is a
>> URL. DDDS is typical of the second and was certainly intended
>> to be the dominant, "standard", one.  The third is most of
>> what my recent note was talking about and includes such
>> things as ISBN and ISSN URNs.  The fourth group is pretty
>> obvious, but we should not forget it is out there -- and
>> Peter's note reminds us that that a single NID may be used,
>> in different contexts, as either a resolvable object
>> (typically (3) but maybe (2)) and as such "no resolution
>> required or expected" names.
> 
> different terms.  For instance, fetching a web page based on a
> URL involves a tremendous amount of indirection (including not
> only DNS but the routing table of every router along the
> path).  But in practice, the required indirections are
> well-specified, and conceptually we consider the *meaning* of
> the URL to be the *result* of the resolution process (and/or
> the specified resolution actions themselves).

Right, although, at the same time, that "meaning" can change.
If http://flowers.example.com/ led today to a web page whose
first line was "the flowers that bloom in the spring", trying it
again next week might produce one (at the same well-specified
location/indirections) whose first line began "'Twas brillig,
and the slithy toves".   More on that below, but the distinction
is, I believe, very much where the "persistent identifier"
discussion begins.

> A similar example is SIP URIs, which aren't called URLs, but
> have much the same properties:  There is a rigidly specified
> resolution process, and the meaning of the URI is still
> closely identified with the result of the resolution process.
> There is some difference, though, because there are "address
> of record" URIs (like telco directory listings) that are
> expected to be attached to individuals, organizations, and the
> like, whose sociological meaning will change less quickly than
> the identity of the SIP servers to which the URI routes.

Right.  But, in parallel to the above, telco directory listings
are only temporarily bound to "individuals, organizations, and
the like".  The binding is a lot less temporary than it was in
the days before number portability and it certainly takes more
to change one than it does for the "owner" of
"flowers.example.com"  to change that hypothetical web page, but
"persistence" if the identifier binding to that final object is
still somewhat dubious.
 
> But once we get to ISBN and ISSN, the meaning is much detached
> from resolution.  In particular, there are assumed to be many
> different ways of resolving the identifier (for various
> purposes), and no one of them is expected to yield "the"
> meaning.

And here is where I get confused about where you are going
because, e.g., an ISBN, once assigned, very much identifies an
object.  If the object changes, the ISBN changes.  There are
well-defined rules requiring those changes and rules that are at
least fairly well-defined globally about what "change" means.
Once assigned to an object, the ISBN itself not only never
changes but is never reassigned to something else.   And, for
ISBNs, "never" means "never" -- not "after a while" or even
"after a decent period of time has passed after the former
subscriber stopped using it.

> The extreme of this end of the spectrum are identifiers like
> the urn:ietf:params URNs -- there is no particular
> network-accessible resource involved, and no resolution
> process (in the ordinary sense) at all.

Yes, we agree about that.

> (draft-ietf-salud-alert-info-urns), which tell phones how to
> announce an incoming call (priority, internal/external source,
> etc.).  In that case, there is a resolution algorithm, but it
> functions entirely inside a phone, instructing how the phone
> should choose from among the ringing signals that it is
> capable of generating which one to choose (e.g., which
> information it should prioritize when it can't announce all of
> the specified information).  So though the URN is tightly
> identified with the resolution process, the resolution process
> does not determine a network-accessible resource.

Right.

But examples like that may also illustrate a different version
of the library/ museum/ etc. requirement.   With the
understanding that there are always tradeoffs and that I don't
pretend to understand that ones that underlay that spec --
particularly why one would want to bother with a URN rather than
an extensible list of keywords and, for some of them, allowable
values -- I note that, if one wanted to make that information
globally available (which might have privacy implications --
again, there are tradeoffs), one might go with an ordinary SIP
URI and some type of "alert" qualification.  Whatever that
qualification might be, it certainly is not a "query" or
"fragment" for the SIP URI or the pseudo-telco object it
represents.   Probably --I've skimmed the spec only quickly--
the nature of the transaction handshake and the proxy issues
mentioned would prevent a "unified URL" approach, but I trust
you see the point.

    john

p.s. you can expect me (or, now that it has come up, someone
else), to question the use of a URN structure on IETF Last Call.
As a co-author, you might want to preempt such questions by
explaining the choice in the draft.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 May 2014 19:34:51 -0600

> and doesn't, in the traditional sense, resolve it at all.

Absolutely correct - for our use in the Jingle XMPP extensions, it's 
just an indicator of support for the offer/answer model.

> wants to think about "permanence", one has to do that work...

I admit that I'm happy to merely help define the URN syntax, not the 
resolution rules.

> to be in terms of levels of abstraction and indirection such at

Yes, that does seem to be a helpful exercise for those who are defining 
NIDs. Do we perhaps need some text along these lines in 3406bis?

Peter

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 28 May 2014 14:45:06 -0400

> object.

Aye, but let's look at it in a couple of different ways.

One way to look at it is from the network engineering point of view.
An ISBN identifies "a book", but that isn't a network-accessible
resource, and so it's pretty much irrelevant.  If you're trying to get
any information via the internet about the book, what you're really
getting is various network-accessible resources that are only
sociologically connected to "the book".  Many of these are considered
"metadata" (cataloging information, current price on the used book
market, etc.) but some might be seen as semantically overlapping "the
book", such as a recording of the book's text or page images from the
book.

Our concept that the ISBN identifies "a book" diverges from the
reality that anything you can do with the ISBN on the internet is at
best a small subset of the information connected to "the book".  In
this regard, an ISBN URI is much more abstracted than an HTTP URI.

To add a layer of complexity, the "book" object that an ISBN
identifies is an abstraction.  I mean, there is a *book* on my desk at
this moment, but the ISBN printed on that book doesn't really identify
that object -- the ISBN identifies the entire set of existing and
potential books that are "from the same edition" (or whatever the
proper technical term is).  And this concept of an object is even
farther from the network engineering, because it isn't even a
physically describable thing.  (Of course, the library/publisher
people understand this, but it's an example that are hierarchies of
concepts that we often blithely lump together as "objects", and then
expect them to behave in generally similar ways.)

Dale