Subject: Re: [urn] suggested change for -12 of rfc2141bis section 7.3.6

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Fri, 01 May 2015 10:10:45 -0400

Not sure I'm entirely getting this right, but ISTM the proposed text 
would support:

1/ Me using urn:isbn:<blat>  in a local resolver in my house to resolve 
to items in my book collection.  (And teddy bears.  Because we know 
about ISBNs).

2/ Me standing up a completely independent URN resolution service for 
all registered URN namespaces and resolving them any way I choose -- 
i.e., not necessarily to the resources intended by the namespace creator 
and/or assigner.  And it's not clear to me how others would be able to 
determine the intended resolution service outcome.

I think "1/" isn't preventable, but shouldn't be promoted.  I think "2/" 
needs to be prevented to the extent possible.

RFC2276 is a pretty broad net.

Leslie.

On 5/1/15 1:23 AM, Keith Moore wrote:
> For reference, the current (-11) text of section 7.3.6:
>
> 7.3.6.  Resolution
>
>     The "Resolution" section MUST specify whether resolution mechanisms
>     are supported or anticipated for URNs assigned within the namespace,
>     and if so SHOULD specify or reference the rules governing those
>     mechanisms.
>
>     In particular, if resolution is anticipated and resolver registration
>     of some kind is required, for example via a Resolution Discovery
>     System [RFC2276], this section SHOULD list the requirements for
>     becoming a recognized resolver of URNs in the relevant namespace.
>
> I believe this section needs work for multiple reasons:
>
>   * resolution is, fundamentally, not a per-namespace operation. A
>     namespace can support a resolution service for URNs that it assigns
>     if it chooses to do so (and it will likely have high quality
>     information), but any other party can also provide a service to look
>     up URNs from any namespace.   Tying resolution services to any
>     specific party degrades the persistence of URNs, because a URN
>     should remain valid and potentially resolvable even if its namespace
>     (or the organization operating it) ceases to exist, or even if its
>     namespace imposes barriers to use of its resolution services.
>   * Rules for resolution should not be namespace-specific, because this
>     discourages general-purpose resolution services.   (A namespace can
>     of course recommend specific resolution services and/or specific
>     protocols for use with those services, but this section is worded as
>     if resolution itself were some sort of fundamentally
>     namespace-specific operation)
>
> Here's a stab at alternate text:
>
> 7.3.6. Resolution
>
>     The "Resolution" section is optional.  If included, it SHOULD
> specify whether the namespace intends to operate or recommend any
> resolution services for URNs using that namespace.   In addition, if the
> namespace intends to implement registration for publicly-advertised
> resolution services (for example using a system like that described in
> [RFC2276]) the Resolution section SHOULD list the requirements for being
> publicly-advertised using that mechanism.
>
> Note: The above is not intended to restrict URN resolution to services
> provided by or recommended by the namespace operator. In principle, any
> party may operate a resolution service for any set of URNs.
>
>
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 01 May 2015 10:17:35 -0400

On 05/01/2015 10:10 AM, Leslie Daigle (ThinkingCat) wrote:
> 1/ Me using urn:isbn:<blat>  in a local resolver in my house to 
> resolve to items in my book collection.  (And teddy bears. Because we 
> know about ISBNs).
>
> i.e., not necessarily to the resources intended by the namespace 
> creator and/or assigner.  And it's not clear to me how others would be 
> able to determine the intended resolution service outcome.
>
> I think "1/" isn't preventable, but shouldn't be promoted.  I think 
> "2/" needs to be prevented to the extent possible.
I disagree.  Anybody should be able to operate a URN resolution service 
for any reason that they choose.  In particular, it's completely 
reasonable for any library to allow its holdings to be looked up by URN, 
or for there to be resolution services that aggregate catalogs from 
several libraries.    It's also completely reasonable for any enterprise 
to operate a URN resolution service for its own holdings, including 
those holdings only accessible to members/employees of that 
organization.   And it's perfectly reasonable for users to configure 
their clients to query any resolution service available to them, 
including multiple services for the same namespace.

Saying that there should be no private resolution services is like 
saying that libraries or booksellers shouldn't permit their catalogs to 
be searched by ISBN.

To be clear, I'm certainly not proposing that all such resolution 
services should be publicly advertised for general use.

Keith

p.s. I'm currently writing a short document on URN resolution that 
illustrates how this works.

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Fri, 01 May 2015 15:48:39 -0400

I certainly appreciate the use cases you cite.    We had a BoF about 
that a decade and a half ago, remember?  C15N.  Contextualization. (More 
info/reminders at  http://web.thinkingcat.com/wordpress/attic/#c15n ).

But, it seems to me your model completely divorces the namespace from 
resources, and allows for any kind of mapping between the two, with no 
ability to detect which mapping the resource holder (or name minter) 
intended.  I don't see that as "permanence" or "persistence".

The danger in conflating the use of an identifier in some consensual 
mapping service with namespace-supported resolution is that you lose any 
ability to use a URN to find the authoritative response intended for a 
given URN.

Leslie.

---

From: Keith Moore <[email-masked]>
Date: Fri, 01 May 2015 16:04:06 -0400

On 05/01/2015 03:48 PM, Leslie Daigle (ThinkingCat) wrote:
> that a decade and a half ago, remember?  C15N. Contextualization. 
> (More info/reminders at 
> http://web.thinkingcat.com/wordpress/attic/#c15n ).

I remember a lot from 15 years ago (or so I like to tell myself), but 
not that BOF.

> intended.  I don't see that as "permanence" or "persistence".

I do see it as promoting persistence.   What I think is detrimental to 
persistence is to promote the notion that only a resolution service 
operated by or authorized by a namespace is valid for resolution.   
If/when a namespace is no longer used to create new URNs and/or the 
organization running a namespace is no longer viable, the old URNs 
produced by that namespace should still be valid.

However, users will naturally want the best resolution information they 
can find, and if namespaces do a good job of providing and recommending 
resolution services for their URNs, and those services are generally 
available, I believe users will prefer them.   But even in those 
circumstances there are valid use cases for other resolution services 
than those advertised by a namespace - again: the local library, your 
company's private library, a preferred bookseller or two.

> mapping service with namespace-supported resolution is that you lose 
> any ability to use a URN to find the authoritative response intended 
> for a given URN.

Not so.   But you do need a mechanism to tell your software which 
resolution services are authoritative, and which of the services are 
preferred over others.

Keith

p.s.  Again, I'm trying to address this in the short document I'm 
writing, but I've been tied up dealing with a First Amendment emergency 
today so probably won't get it done before the weekend.

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Mon, 04 May 2015 17:20:04 -0400

In-line...

> I remember a lot from 15 years ago (or so I like to tell myself), but

How's your recollection on RESCAP? 
http://web.thinkingcat.com/wordpress/attic/#rescap

> operated by or authorized by a namespace is valid for resolution.

Great, whatever you want to do to data in your own networks, have at it.

But, in other contexts, overriding intended network actions with a 
different flavour is considered "hijacking", and we generally try to 
avoid it.

> produced by that namespace should still be valid.

Valid for what?  How does some other entity know what they were meant to 
point to (authoritatively)?

In terms of wholesale changing of resolution services in a conscious and 
intentional way, that was part of the purpose of DDDS.  Which this 
generation of WG discussion seems to have thrown out with the 
implementation in DNS.

> company's private library, a preferred bookseller or two.

I agree that there are valid use cases for finding other copies of 
resources.  I disagree that should be conflated within the resolution 
system.
> resolution services are authoritative, and which of the services are

All strictly IMO:   It's not a mechanism.  It's got to be part of the 
standard.  Software is something people write to implement the standard, 
and is not the subject of discussion here.

Leslie.

---

From: Keith Moore <[email-masked]>
Date: Mon, 04 May 2015 17:50:24 -0400

> http://web.thinkingcat.com/wordpress/attic/#rescap

A bit better.   Thanks for the pointer to that; some of us were just 
talking about RESCAP in Dallas.

> different flavour is considered "hijacking", and we generally try to 

I don't view URNs as inherently tied to "intended network actions". The 
URN system is a discipline for naming resources.    Now it happens that 
it's frequently useful to be able to ask network-based services for 
information about URNs.   But which services are "authoritative" sources 
of information about a URN depends on what you're looking for.   If 
you're looking for the information which the namespace itself associates 
with that URN, the best service to consult is probably one either 
operated by or recommended by that namespace.   If you're looking for a 
copy of that resource on a particular library or archive, you probably 
want to ask that library or archive, because it is authoritative for 
that kind of information.   That's not "hijacking", it's just a 
different use case.

OTOH, it's extremely dangerous to architect a single source for all 
information about a URN.  Single sources provide excellent vectors for 
denial-of-service attacks, control of information usage, and monitoring 
of information usage - all of which are threats to a free society.

> Valid for what?  How does some other entity know what they were meant 
> to point to (authoritatively)?

How does someone today know what an ISBN created long ago was meant to 
point to?   As best as I understand, the answer is that there are 
organizations that compile such information and make their databases 
available.

> In terms of wholesale changing of resolution services in a conscious 
> and intentional way, that was part of the purpose of DDDS.  Which this 

IMO, DDDS needs another look.   I think some of those documents suffer 
from lack of clarity but the underlying ideas were fairly sound.   There 
definitely needs to be a way to discover namespace-advertised services 
that provide information about URNs. I just don't think that those 
services are the only sources that should ever be consulted.

> resources.  I disagree that should be conflated within the resolution 

Well, if it's just a matter of what we call each operation, I don't care 
that much.  Having different terms for the two might be useful.   I 
would however like for software to be capable of consulting both 
namespace-recommended and other sources of information about a URN 
(depending on the use case); and for some of the same protocols, schema, 
and data formats to be potentially usable across those different use cases.

> standard.  Software is something people write to implement the 
> standard, and is not the subject of discussion here.

Again, I think there are different kinds of authority, and the namespace 
isn't the only source of authoritative information for every use case.

But of course we do need to be clear about what's part of the standard 
and what's merely an implementation recommendation or suggestion.

Keith

p.s. thanks for this message though - responding to it helped to clarify 
for me that the use case associated with a URN needs to guide the 
implementation's choice of which services to consult, and also that the 
use case is probably something that should be able to be exposed in an 
r-component.   more on that later, hopefully later tonight.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 26 May 2015 17:09:51 -0600

>     namespace imposes barriers to use of its resolution services.

URNs from many NIDs are not intended to be resolvable at all, i.e., they 
are what we have termed "abstract designators". Most or all of the URNs 
used as XML namespace names are abstract designators.

>     The "Resolution" section is optional.

It seems safer for all sections of the template to be mandatory. If no 
resolution is envisioned (primarily because the URNs for a given 
namespace are intended to be abstract designators), then it's good to 
make that explicit here.

> If included, it SHOULD
> resolution services for URNs using that namespace.

I don't think a namespace can operate a resolution service! :-) But I 
suppose you meant something like "the organization responsible for a 
namespace".

>  In addition, if the

I think that's acceptable. I know Leslie is concerned about rogue 
resolution services, but if the organization that assigns URNs in a 
namespace is able to specify its requirements for appropriate resolution 
of those URNs, then we have some mechanism for determining if a service 
is resolving those URNs in a way that is consistent with the assigning 
organization's intent.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 26 May 2015 17:17:21 -0600

> is resolving those URNs in a way that is consistent with the assigning

I propose the following text:

    The "Resolution" section MUST specify whether resolution mechanisms
    are intended or anticipated for URNs assigned within the namespace
    (e.g., URNs within some namespaces are intended to act as abstract
    designators and thus are not intended to be resolved).

    If resolution is intended, then this section SHOULD specify whether
    the organization that assigns URNs within the namespace intends to
    operate or recommend any resolution services for URNs within that
    namespace.  In addition, if the assigning organization intends to
    implement registration for publicly advertised resolution services
    (for example using a system like that described in [RFC2276]), then
    this section SHOULD list or reference the requirements for being
    publicly advertised by the assigning organization.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 May 2015 23:30:53 -0400

>    publicly advertised by the assigning organization. 

Mumble.

1. I agree that a URN namespace* that assigns its URNs only for use as 
"abstract designators" rather than as resource names should state this 
in the namespace registration.

<rant>
IMO, such URN namespaces should never have been granted; this was and is 
a misuse of URNs.  But that water has long since passed under the bridge 
at least for some existing namespaces.   The only reason that I think 
this is useful to have in the namespace registration is that a 
namespace* that only intends that its URNs be used as "abstract 
designators" is unlikely to exercise any control whatsoever about the 
association of such names with resources, so the URNs that they assign 
really aren't usable as persistent resource names.   In effect, putting 
this flag in the namespace registration is equivalent to saying 
"Warning: these are not really URNs."   Because Uniform Resource Names 
really were intended to be Resource Names, not merely "abstract 
designators" no matter how widely URNs have been misused for the latter.
</rant>

2. I also agree that a namespace* that intends to operate or recommend 
any resolution services should state this in its namespace registration.

What I don't think is appropriate is for the registration to specify 
whether resolution mechanisms are "intended or anticipated", since 
that's really not up to the namespace*.

So what I would propose is to not put the first question in the 
Resolution section, but to have a separate question for that:

     Are all of the URNs assigned (currently or in the future) under this
     namespace intended exclusively for use as "abstract designators",
     that is, never as names of actual resources?  (yes or no)

Then the Resolution section text would look something like this:

     If the URNs assigned under this namespace are intended exclusively
     for use as "abstract designators" this section should read "Not 
Applicable".

     If any of the URNs assigned under this namespace are intended for 
use as
     resource names, the Resolution section SHOULD specify
     whether the assigning organization intends to operate or
     recommend any resolution services for URNs within that
     namespace.  In addition, if the assigning organization intends to
     implement registration for publicly advertised resolution services
     (for example using a system like that described in [RFC2276]), then
     this section SHOULD list or reference the requirements for being
     publicly advertised by the assigning organization.

Keith

* almost but not quite a shorthand for "organization operating a 
namespace" - since the rules for operating the namespace should continue 
to apply even if the organization changes.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 26 May 2015 21:53:24 -0600

> designators" no matter how widely URNs have been misused for the latter.

I would hazard that a preponderance of the formal namespaces approved so 
far exist for the purpose of assigning abstract designators:

http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

Thus tilting at that particular windmill strikes me as futile.

> that's really not up to the namespace*.

Well, it is, but see below.

>      that is, never as names of actual resources?  (yes or no)

Fair enough - that's another way to ask the question about intentions.

(BTW in -12 we'll have some text that attempts to define the concept of 
"abstract designator" more clearly.)

>      publicly advertised by the assigning organization.

WFM.

> to apply even if the organization changes.

Right, it's the rules that matter - the rules define the namespace and 
the assigning organiation follows the rules. Or so we hope. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 May 2015 00:41:57 -0400

On 05/26/2015 11:53 PM, Peter Saint-Andre - &yet wrote:
> I would hazard that a preponderance of the formal namespaces approved 
> so far exist for the purpose of assigning abstract designators:
>

Those namespaces would be mostly harmless, except that people keep 
making assumptions about how URNs are supposed to work based on those 
mistakes.

> Well, it is, but see below.

No it's not.   It might not matter for the current discussion, but it's 
really important to understand that the namespace does not control 
resolution.

> (BTW in -12 we'll have some text that attempts to define the concept 
> of "abstract designator" more clearly.)
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 May 2015 07:57:33 -0400

--On Wednesday, May 27, 2015 00:41 -0400 Keith Moore
<[email-masked]> wrote:

>...

>>> Mumble.
>>> 
>>> 1. I agree that a URN namespace* that assigns its URNs only
>>> for use as "abstract designators" rather than as resource
>>> names should state this in the namespace registration.
>>> 
>>> <rant>
>>> IMO, such URN namespaces should never have been granted;
>>> this was and is a misuse of URNs.  But that water has long
>>> since passed under the bridge at least for some existing
>>> namespaces.   The only reason that I think this is useful to
>...
>>> intended to be Resource Names, not merely "abstract
>>> designators" no matter how widely URNs have been misused for
>>> the latter. </rant>

For the record, while I'm picking up on some comments that Keith
wrote, he is not the only one and this is not specifically about
him.

Personal opinion/request: I understand the reason for these
sorts of rants/ comments from those who had (or believed they
had) a very clear view of URNs years ago (and whether they are
explicitly identified or not).  They pose two difficulties and I
wish they would stop.  

First, not only is it water under the bridge, but the door has
closed.  Perhaps early documents should have described several
types of URNs and identified multiple types with multiple
schemes (reserving the term "URN" itself as "URL" is effectively
reserved).  They/we didn't do that and, as Peter points out,
probably most of the URNs in use today do not conform to those
early assumptions in one way or another.      While it arguably
made things worse, the text in RFC 3986 that says that there are
such things as "URN"s and that only some of them conform to the
"urn:" scheme, it at least was an attempt to address the issue.  

For the same reason, I object to anything resembling a casual
reference to RFCs 1737, 2276, or the 2915, 2168, and 3401 family
in 2141bis.  Common, probably dominant, practices have evolved
past those documents, 3401 and friends have not been broadly
used and adopted and general-purpose NAPTR records have proven
problematic, and so on.  We don't add clarity to what URNs are
about today (and in the likely future) by citing those
documents, even as examples.  What we do is to add confusion or
at least fodder for the next rounds of nit-picking arguments and
moral outrage about certain types of usage.

I think there is a place for a reprise and summary in the form
of an updated theory of URNs and URN resolution -- a document
that would presumably obsolete 1737 and 2276 and comment on the
applicability of DDDS (and hence 3401ff).  But it doesn't appear
to be to be within scope for this WG.  Even if it were, it is
fairly clear we don't have the energy for it.

The other problem is that hair-splitting arguments about the
true nature of URNs (etc.) drives people with more pragmatic
interests and less time away from  the WG, leading to a
situation in which we have long-thread discussions, typically
about esoteric (if not irrelevant) issues among a handful of
people, losing broader perspectives and review.

Can we just stop?  If we cannot stop, might I encourage the
co-chairs to start weighing the impact of such discussions on WG
progress with an eye to identifying them as disruptive?

>...

Worse than futile.  IMO, they are making it much more difficult
for the WG to make anything resembling progress.

> Those namespaces would be mostly harmless, except that people
> keep making assumptions about how URNs are supposed to work
> based on those mistakes.

See comments about "updated theory" above.  If someone wants to
write that document and discuss it -- but not on this WG's list
at least until after we get 2141bis published -- I'm willing to
read it and review.   But I don't think comments about
"mistakes" in very wide use on this list are helpful unless they
are also actionable and contain specific proposals for text that
would fit into 2141bis and that do not involve turning back the
clock.

>>> 2. I also agree that a namespace* that intends to operate or
>>> recommend any resolution services should state this in its
>>> namespace registration.
>>> 
>>> What I don't think is appropriate is for the registration to
>>> specify whether resolution mechanisms are "intended or
>>> anticipated", since that's really not up to the namespace*.
>> 
> No it's not.   It might not matter for the current discussion,
> but it's really important to understand that the namespace
> does not control resolution.

Until we provide more resources --and perhaps whips or guns-- to
the Protocol Police -- nothing we specify controls anything
else.  "Intended or anticipated" is an intended/expected best
practices statement, not a statement about "control".     And,
again, these hair-splitting discussions are hurting us.

And, if we are going to make a distinction between "abstract
designator" and something else, I hope we can come up with a
different term than "resource name", if only because "when is a
Uniform Resource Name not a resource name" is not just a trivia
contest question but an invitation to precisely the sort of
historical hair-splitting that I hope we can avoid.

>...

best,
    john

---

From: Andrew Newton <[email-masked]>
Date: Wed, 27 May 2015 15:48:35 -0400

Well said, John.

-andy

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 May 2015 16:00:55 -0400

> explicitly identified or not).  They pose two difficulties and I

I agree at least to the extent that we're generally better off focusing 
on the proposed text rather than philosophical arguments. I think 
2141bis is moving in the right direction, and that we're close to having 
some good compromises, and I appreciate that.    I'm just concerned 
because I see potential for some of these misunderstandings about URNs 
to creep into the document text, either explicitly or more likely by 
omission, and I really don't want to see this WG make those problems any 
worse than they already are. If it weren't for that potential, I'd 
happily reserve my discussions on these subjects to bar BOFs and private 
mail.

I also don't think it's either constructive or appropriate to dismiss 
the opinions of those who invested huge amounts of time 20+ years ago 
into forging an understanding of how URNs needed to work, or the 
consensus documents that they produced, as dated, irrelevant, or 
illusory.    Insults such as these demand responses, responses snowball, 
and the tendency is for those discussions to become ugly.   I think 
those discussions are much more of a deterrent to making technical 
progress than discussions about the meaning of URNs - whether or not you 
label them as hair-splitting.

Early uses of URNs should not be taken as an indicator of how URNs will 
or should be used in the long run, any more than early uses of IPv6 
should be taken as an indicator of how IPv6 will or should be used in 
the long run.  I understand the desire to reconcile the intended purpose 
of URN with current practice, even when that practice is peripheral to 
the purpose of URNs.   And that's fine with me as long as we don't 
degrade the ability of URNs to serve their intended purpose.    The 
"millions of URNs" that I keep hearing about that have been produced by 
libraries and archives are very much within the intended purpose of URNs 
(though the intended scope of URNs is somewhat broader than that), but 
abstract designators are not.   So abstract designators shouldn't be 
cited in arguments for how URNs are supposed to work, any more than 
Heartbleed should be used to support an argument that TLS should permit 
hostile attacks.

Keith

---

From: Andrew Newton <[email-masked]>
Date: Wed, 27 May 2015 16:13:11 -0400

On Wed, May 27, 2015 at 4:00 PM, Keith Moore <[email-masked]>
wrote:

> I also don't think it's either constructive or appropriate to dismiss the
> opinions of those who invested huge amounts of time 20+ years ago into
> forging an understanding of how URNs needed to work, or the consensus
> documents that they produced, as dated, irrelevant, or illusory.    Insults
> such as these demand responses, responses snowball, and the tendency is for
> those discussions to become ugly.   I think those discussions are much more
> of a deterrent to making technical progress than discussions about the
> meaning of URNs - whether or not you label them as hair-splitting.

I don't think insults were intended.

But when outsiders see 20 year-old arguments being rehashed, they tend to
think "religion" and move on. It makes getting review of our documents more
difficult.

-andy

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 May 2015 16:17:16 -0400

On 05/27/2015 04:13 PM, Andrew Newton wrote:
>
> On Wed, May 27, 2015 at 4:00 PM, Keith Moore 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I also don't think it's either constructive or appropriate to
>     dismiss the opinions of those who invested huge amounts of time
>     20+ years ago into forging an understanding of how URNs needed to
>     work, or the consensus documents that they produced, as dated,
>     irrelevant, or illusory.    Insults such as these demand
>     responses, responses snowball, and the tendency is for those
>     discussions to become ugly.   I think those discussions are much
>     more of a deterrent to making technical progress than discussions
>     about the meaning of URNs - whether or not you label them as
>     hair-splitting.
>
>
> But when outsiders see 20 year-old arguments being rehashed, they tend 
> to think "religion" and move on. It makes getting review of our 
> documents more difficult.
>
> -andy

So we're basically supposed to ignore all of the history and thinking 
and consensus that went into URNs and just accept whatever the document 
authors say?

Keith

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 May 2015 12:29:31 -0800

> and consensus that went into URNs and just accept whatever the document

No, of course not.  I think the concern here is that discussion
stay rooted in engineering considerations, and that objections
that are raised should be as specific as possible about what would
break and why that's a problem.  In the interest of producing a
usable, useful spec we do need to stay focused on engineering
considerations.

Melinda

---

From: Andrew Newton <[email-masked]>
Date: Wed, 27 May 2015 16:31:58 -0400

On Wed, May 27, 2015 at 4:17 PM, Keith Moore <[email-masked]>
wrote:

> So we're basically supposed to ignore all of the history and thinking and
> consensus that went into URNs and just accept whatever the document authors
> say?

Keith,

There is quite a bit of distance between the point I was making and the
conclusion you seem to have drawn.

-andy

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 May 2015 17:07:47 -0400

> usable, useful spec we do need to stay focused on engineering

I'm entirely concerned about things that have the potential to affect 
interoperability and applicability of URNs.   I think those qualify as 
engineering concerns.   But there's a lot of subtlety to URNs, and the 
URN specifications reflect a lot of carefully-considered decisions that 
were made for reasons that are not exposed in those specifications and 
perhaps not obvious.

So whenever some proposal has the potential to affect interoperability 
or applicability of URNs, I think it's reasonable to discuss the 
thinking behind those decisions.   It's not that I want to rehash old 
discussions, but sometimes it seems like the simplest way to explain why 
a particular proposal to change URNs, namespace registration, etc. might 
do harm.

Keith

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Wed, 27 May 2015 18:07:27 -0400

FWIW, I’m not just worried about “rogue”, I’m worried about 
having a plethora of available tools to apply to URNs and no way to 
determine what the minter of the URN intended.

And, I believe that’s a change of the spec.

Leslie.

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------
On 26 May 2015, at 19:09, Peter Saint-Andre - &yet wrote:

> URNs from many NIDs are not intended to be resolvable at all, i.e., 
> they are what we have termed "abstract designators". Most or all of 
> the URNs used as XML namespace names are abstract designators.
>
> namespace is able to specify its requirements for appropriate 
> resolution of those URNs, then we have some mechanism for determining 
> if a service is resolving those URNs in a way that is consistent with 
> the assigning organization's intent.
>
> Peter
>
> -- 
> Peter Saint-Andre
> https://andyet.com/
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 27 May 2015 21:02:24 -0600

On 5/27/15 4:07 PM, Leslie Daigle (ThinkingCat) wrote:
>
> FWIW, I’m not just worried about “rogue”, I’m worried about having a
> plethora of available tools to apply to URNs and no way to determine
> what the minter of the URN intended.
>

I seem to be in the rough about my desire to remove all discussion of 
resolution from the syntax and registration specification. Every time we 
talk about resolution, we seem to fall down a rat hole of unusual size. 
Since we're not replacing RFC 2276 in parallel with replacing RFC 2141 
and RFC 3406, I feel like we're flying blind with respect to all 
resolution-related topics.

Just my $0.02.

Peter

---

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 28 May 2015 14:32:41 +0000

Keith,

> were made for reasons that are not exposed in those specifications and

Then we should ensure that those considerations and their raisons-d'être are exposed in future specifications. I think that would help future reviewers to go down the same ratholes that we seem to do.

/Lars

---

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 28 May 2015 14:49:33 +0000

Peter,

> resolution-related topics.

If I understand you correctly, your suggestion is concentrate on syntax (and as little semantics as possible) making 2141bis fly as soon as possible. Once that is done, we go on to revise 3406. WFM. That said, I don't think we can specify registrations procedures without discussion resolution since one important aspect of persistent naming is the ability to find the named object through its name. And in most cases this is done through some kind of lookup service and it is indeed an important question who has the canonical registry. I don't think we can offload that on to IANA...

Best,

Lars

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 May 2015 17:15:16 -0400

> what the minter of the URN intended.

I think we absolutely need a plethora of available tools to apply to URNs.

I also think we need a way to determine what the minter of the URN 
intended.   However, for security reasons I suspect this needs to rely 
at least as much on digital signatures and a certificate hierarchy, as 
it relies on a registry of resolution services.

I'm happy to try to sort this stuff out as part of a discussion of 
resolution and associated registries.   I don't see offhand how any of 
this affects a discussion of URN namespace registration, unless we want 
2414bis to ask namespaces to supply their public keys as part of 
registration.

Keith

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 28 May 2015 18:17:37 -0600

> If I understand you correctly, your suggestion is concentrate on syntax (and as little semantics as possible) making 2141bis fly as soon as possible. Once that is done, we go on to revise 3406. WFM…

I'm suggesting that we concentrate on syntax (2141bis) and namespace 
registrations (3406bis) - those are easier to specify because we have 
more experience with them. We don't have experience with URN resolution 
or at least those folks haven't been involved here, so I suggest that we 
updated RFC 2276 separately and address the resolution-related topics then.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 29 May 2015 07:35:00 +0000

On Friday, May 29, 2015 2:18 AM, Peter Saint-Andre - &yet wrote
> > If I understand you correctly, your suggestion is concentrate on syntax (and as
> little semantics as possible) making 2141bis fly as soon as possible. Once that is
> done, we go on to revise 3406. WFM. That said, I don't think we can specify
> registrations procedures without discussion resolution since one important
> aspect of persistent naming is the ability to find the named object through its
> name. And in most cases this is done through some kind of lookup service and it
> is indeed an important question who has the canonical registry. I don't think we
> can offload that on to IANA...
> 

But can we really specify the registration procedure without asking the registrants to say anything about resolution services?

Lars

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 May 2015 06:33:10 -0400

> But can we really specify the registration procedure without asking the registrants to say anything about resolution services?
I don't think we can effectively bundle the namespace registration 
procedure with the procedure for registering namespace-specified 
resolution services, for several reasons, e.g.:  the information 
required to access such services isn't defined yet, won't be defined 
until we know something about resolution protocols and security models, 
and is likely to change more frequently than namespace registration.   
So I think we will end up with separate procedures for namespace 
registration and for registration of resolution services, and there's no 
need to try to specify the latter in 2141bis.

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 May 2015 08:32:40 -0400

Hi.

It is possible that we are arguing about an already-solved
problem here.  Or not... see below.

--On Thursday, May 28, 2015 18:17 -0600 Peter Saint-Andre - &yet
<[email-masked]> wrote:

>>> I seem to be in the rough about my desire to remove all
>>> discussion of resolution from the syntax and registration
>>> specification. Every time we talk about resolution, we seem
>>> to fall down a rat hole of unusual size. Since we're not
>>> replacing RFC 2276 in parallel with replacing RFC 2141 and
>>> RFC 3406, I feel like we're flying blind with respect to all
>> If I understand you correctly, your suggestion is concentrate
>> on syntax (and as little semantics as possible) making
>> 2141bis fly as soon as possible. Once that is done, we go on
>> to revise 3406. WFM. That said, I don't think we can specify
>> registrations procedures without discussion resolution since
>> one important aspect of persistent naming is the ability to
>> find the named object through its name. And in most cases
>> this is done through some kind of lookup service and it is
>> indeed an important question who has the canonical registry.
>> I don't think we can offload that on to IANA...
> 
> I'm suggesting that we concentrate on syntax (2141bis) and
> namespace registrations (3406bis) - those are easier to
> specify because we have more experience with them. We don't
> have experience with URN resolution or at least those folks
> haven't been involved here, so I suggest that we updated RFC
> 2276 separately and address the resolution-related topics then.

Let me try this a slightly different way, but reaching the same
conclusion.  As Peter points out, we know, or are close to
knowing, how to update and replace 2141 and 3406.  We also have
very specific problems that we are trying to solve.  In the case
of 2141, allowing, for various reasons and in response to
various requirements, more syntax than 2141 permits: the things
we've been calling q-components and r-components; the
f-components / fragments that some of the opinions on RFC 3986
claim that 2141 could not disallow if it wanted to; and either
the use of the "/" within the NSS or p-components.  In the case
of 3406, it establishes a registration procedure for namespaces
that has been perceived as sufficiently onerous to discourage
namespaces from being registered, something I think we've
concluded is a bad idea.

Now, if we start looking at resolution, we end up not only in
the territory of 2276 but also 3401ff.  There are some
historical issues with 2277 related to how much consensus it
represented at the time and how informed that consensus was.  It
is an Informational, rather than a Standards Track, document,
which may or may not mean much.    More important today, 3401
(and 3402-3405) claim to be a more or less consistent
implementation spec for the ideas in 2276, modifying those ideas
slightly in the process.  With the exception of one, non-URN,
application, DDDS has not been broadly adopted or used.
Anything that was proposed today and based on any of those specs
would almost certainly have to include specific analysis of the
architecture and implementations and what had and had not
succeeded.  To the best of my knowledge, no one has started that
work or even volunteered to do it.

At the same time, most of the URNs we have seen in active use
either don't need resolution services or use resolution
mechanisms intrinsic in other standards or protocols.  URNs used
in XMPP, ISBN and ISSN, and XML all come immediately to mind as
examples.

I think Keith's most recent comments
(http://www.ietf.org/mail-archive/web/urn/current/msg03076.html)
are largely consistent with the above although his perspective
is different.

Briefly addressing a more recent note:

--On Friday, May 29, 2015 07:35 +0000 "Svensson, Lars"
<[email-masked]> wrote:

> But can we really specify the registration procedure without
> asking the registrants to say anything about resolution
> services?

I think we have little choice, for the reasons outlined above
and in Keith's and Peter's notes.   However, we provided some
time ago for comments about resolution when those are
appropriate and I haven't seen proposals to remove those
provisions.  See in particular (in
draft-ietf-urnbis-rfc2141bis-urn-11):

	Section 7.1, numbered item 6     and
	Section 7.3.6

I've expressed some concerns earlier about the second paragraph
of the latter because of the interaction and reference to 2276
(for the reasons above), but don't recall anyone else expressing
interest in that issue.  However, it seems to me that this text
provides mechanisms that allow a registration to say any of the
following in the registration specification:

 (i) This namespace is indicator-only and unlikely to be
	resolved (or resolution would be meaningless).
 (ii) Resources associated with this namespace are
	located and resolved according to the mechanism
	specified in ...
 (iii) While the identifier is universal and persistent,
	registration is likely to be a local matter.
 (iv) We know what these are, aren't ready to say
	anything general about resolution yet, but will update
	the registration when we figure that out.
 (v0 ... and so on

It seems to me that provides a way to record whatever
information is known and which the registrants think is
appropriate to supply while avoiding  unrealistic requirements
to specific things that neither we nor the registrant knows or
requiring that all URNs be resolvable or resolvable in one of an
enumerated set of ways.

What else do you think is both useful and feasible?   Is the
current text ok or would you suggest improvements, particularly
to say either more or less?

	    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 May 2015 11:02:05 -0400

--On Thursday, May 28, 2015 17:15 -0400 Keith Moore
<[email-masked]> wrote:

>> FWIW, I'm not just worried about "rogue", I'm worried
>> about having a  plethora of available tools to apply to URNs
>> and no way to determine  what the minter of the URN intended.
> 

I think we already have them and have no hope of either getting
rid of some or preventing more.  I also don't think the latter
would be desirable even if we could somehow do it.

> I also think we need a way to determine what the minter of the
> URN intended.

The referenced section 7.3.6 of -11 (see prior note) seems to me
to allow the registrant to provide whatever intent is
appropriate (or, if appropriate, to not do so).   I think the
discussion between Keith and Leslie starting on 1 May provides
pointers toward better text for that subsection (see below), but
does not significantly change the intent of leaving decisions
largely up to the registrant about what it is appropriate to say
and how much specific detail to provide.  See below.

>  However, for security reasons I suspect this
> needs to rely at least as much on digital signatures and a
> certificate hierarchy, as it relies on a registry of
> resolution services.

Speaking personally, I believe that a comprehensive reprise of
issues in URN resolution, including issues about data integrity
guarantees and other security topics, would be desirable.  But I
think that opening those topics on this list at this time is not
only off-charter but distracting and a significant impediment to
getting the WG's work done.

I do note that the belief that solutions lie in the direction of
"digital signatures and a certificate hierarchy" invokes
problems that the Internet community has been unable to sort out
and get generally deployed and in effective use for _any_
protocol or application I'm aware of so, at best, this is not an
easily-resolved short-term problem.

Similarly, I am not (as one of Leslie's notes suggested)
inclined to discard DDDS on the basis of issues with the
"implementation in DNS".  However, we know there are issues with
that DNS implementation and, AFAIK, the number of other
widely-deployed implementations is around zero, so a strong
reference to DDDS that seems to hold it up as a good example
seems inappropriate in the absence of some serious analysis and
writing ... about DDDS and the 2276 architecture, not URNs.

> I'm happy to try to sort this stuff out as part of a
> discussion of resolution and associated registries.   I don't
> see offhand how any of this affects a discussion of URN
> namespace registration, unless we want 2414bis to ask
> namespaces to supply their public keys as part of registration.

For the reasons above, I'm opposed to any requirements that
would be specific enough to use words like "supply their public
keys", probably even as examples.  Independent of how we say it,
I think the registration template should encourage registrants
to say whatever they think it appropriate about registration for
that particular namespace and that it should stop there.   I
believe the existing text in 7.3.6 does that.  I believe Keith's
original 1 May text (to save readers time, it was:

> specify whether the namespace intends to operate or recommend
> any resolution services for URNs using that namespace.   In
> addition, if the namespace intends to implement registration
> for publicly-advertised resolution services (for example using
> a system like that described in [RFC2276]) the Resolution
> section SHOULD list the requirements for being
> Note: The above is not intended to restrict URN resolution to
> services provided by or recommended by the namespace operator.
> In principle, any party may operate a resolution service for
> any set of URNs.

) does that.  I think it does so a bit better with Peter's
suggested modifications, e.g., making the "Resolution" section
mandatory even if it ends up saying "not intended to be
resolved", "you are on your own", or "this section should be
updated when appropriate time machines are in use" (see Homeric
example below).  

Suggested modified text, cleaning up the language Peter
questioned and removing the reference to 2276 because it is not
"a system" but a proposed architecture for one (this is a little
more passive and vague about who or what is doing the
specifying, but probably that is appropriate).  I also think we
need to not try to tie things to generic resolution services --
if there are namespace-specific preferred ones, the registration
should identify them:

	If included, it SHOULD specify whether there are
	specific recommended resolution services, operational
	mechanisms, or ways of finding either for URNs using
	that namespace.  In addition, if implementation of
	registration for publicly-advertised resolution services
	(for example using a system such as DDDS [RFC3401] or
	one associated with an external standard) is
	anticipated, this section SHOULD supply the information
	required for being publicly-advertised or otherwise
	using that mechanism.

 ----------

However, I believe that the discussion about text has obscured
two more fundamental issues...

(1) Keith has asserted repeatedly (cf.
http://www.ietf.org/mail-archive/web/urn/current/msg03012.html)
that 

> resolution is, fundamentally, not a per-namespace operation.

I'm not clear as to what that means.  Certainly, in the general
case, a resolution service for one namespace is likely to differ
in more or less significant ways from a resolution service for
another one.  Even a "find the resolution service" model such as
DDDS merely moves the namespace-specific characteristics out one
level of abstraction.

The text later in that note suggests to me that the problem
isn't whether resolution is per-namespace but whether a
particular resolution mechanism or provider is sufficiently
tightly bound to a namespace that no other (or replacement)
registration mechanisms are possible.  I don't think anyone has
suggested that, although it does imply that we need to be
careful about what statements are made and that we carefully
distinguish between stability/ persistence of a URN and
stability/persistence of an associated resource and how it is
found.  

(2)  Leslie, and probably others, have noted that not having a
tight and required binding to resolution services allows

> 2/ Me standing up a completely independent URN resolution
> service for all registered URN namespaces and resolving them
> any way I choose -- i.e., not necessarily to the resources
> intended by the namespace creator and/or assigner. And it's
> not clear to me how others would be able to determine the
> intended resolution service outcome.

I think the response to that has got to be "yes".  It is a risk
for almost any Internet protocol that references or
de-references objects.  For example even with simple URLs, if
http://resource.example.com/ is referenced, nothing prevents
some immediate or intermediate system from converting it into
http://resource.somewhere-near-me.example.com/ (something often
considered a good thing) or http://resource.example.evil-doer/
(something usually consider a bad thing).  Using bad words
(including "hijacking") to describe what we believe are bad
practices doesn't seem to make them less prevalent, nor does it
help distinguish practices, including object-owner-controlled
DNS diversion techniques that are widely deployed and some
vendors (in bad and exceptionally candid moods) would claim have
saved the Internet from stupidity in the DNS, linkages between
URLs and DNS, and wrong-headed ideas in the routing system.   

We claim we know how to let the client interpreting the URL
distinguish between "example.com" and "example.evildoer", but,
for a variety of reasons, that mechanism has been largely
unsuccessful in practice.   And we claim that we know how to at
least verify the integrity of the data retrieved, but we've been
unsuccessful in deploying those mechanisms, especially without
introducing circular dependencies on the DNS.

If a statement is needed in Security Considerations that says
that nothing about a URN guarantees that an attempt to resolve
it will obtain the intended resource, please supply text, but
please remember that this is an extremely general problem and
not unique to URNs.

However, I also suggest that something like
    urn:important-ancient-texts:homer:Illiad-original-version

is a perfectly good URN.  It is about as persistent as anything
in western literary culture can be.  The reference is
unambiguous in the sense that likely users of the URN are going
to agree on what, conceptually, is being referenced.   It is
definitely not an "indicator".  I don't think it is an "abstract
designator" either, but this example illustrates why I'm a
little hesitant about that terminology.   It is not resolvable
in any practical way and there are deep historical questions
(rooted, among other things, in assumptions about texts that may
have existed for a long time in oral form only and even about
whether "Homer" is a historical figure).    Whether such a URN
is useful or not presumably depends on what a possible
registrant wants to use it for -- that isn't a question on which
the IETF should take a position or expect folks to pay attention
if we did.

best,
    john

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 May 2015 11:54:08 -0400

On 05/29/2015 11:02 AM, John C Klensin wrote:
> However, I believe that the discussion about text has obscured two 
> more fundamental issues... (1) Keith has asserted repeatedly (cf. 
> http://www.ietf.org/mail-archive/web/urn/current/msg03012.html) that
> another one.

I don't believe this is at all certain, nor do I believe that it is 
desirable in general.  The whole point of having URNs is to permit some 
degree of common processing that is independent of namespace, including 
the ability to obtain metadata (if available) and/or access the resource 
(if the resource is available and the operation makes any sense for that 
resource).

That said, neither do I want to force a "one size fits all" model on URN 
resolution.   I have several reasons for this, the most important 
probably being that such services need to be able to evolve over time, 
perhaps especially in the near term, and therefore it is necessary that 
it be possible to have different and even competing services.   But 
promoting the idea that resolution is inherently something for each 
namespace to determine on its own, IMO, would harm interoperability.   
Sure, namespaces can offer any resolution services that they want for 
their URNs (or not), but so can anybody else.     And it's extremely 
important that this be possible.

(I also agree that trying to define a resolution service is beyond this 
group's charter, though I think it's reasonable to discuss such issues 
to the extent necessary to nail down text in 2141bis.)

>   Even a "find the resolution service" model such as

Indeed, we need to be careful about what statements are made.

> I think the response to that has got to be "yes".

Again, I think the mechanism for ensuring authenticity of metadata 
and/or resources associated with URNs cannot rely on "a tight and 
required binding to resolution services".    Being able to determine 
authenticity of such metadata and resources is very important, but it's 
also very important that there not be a single point of control for 
access to resources named by URNs.   We don't want to build an 
information architecture that facilitates Orwellian "memory holes" - as 
the US government, as well as probably several others, would certainly 
like to do.

And while I agree that IETF in the past has not had a stellar record at 
developing trust delegation systems, that's not a good argument for 
giving up.   IETF is currently revisiting those issues on several 
fronts, out of perhaps-reluctant necessity, due to the realization that 
both passive surveillance and active attacks on Internet traffic by 
various parties, some with near-limitless resources, are now commonplace 
and widespread.   We should all realize by now that simply trusting the 
authoritative servers for DNS or whatever, is now no longer sufficient.

> the IETF should take a position or expect folks to pay attention

I probably agree with that, or at least agree that it should be 
reasonable to assign a URN to Homer's original text of the Illiad, even 
if such a document has never been found and is believed to no longer 
exist.   I certainly would not want to declare such uses out-of-scope.

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 May 2015 14:49:22 -0400

--On Friday, May 29, 2015 11:54 -0400 Keith Moore
<[email-masked]> wrote:

>> However, I believe that the discussion about text has
>> obscured two  more fundamental issues... (1) Keith has
>> asserted repeatedly (cf. 
>> I'm not clear as to what that means.  Certainly, in the
>> general case, a resolution service for one namespace is
>> likely to differ in more or less significant ways from a
>> resolution service for another one.
> 
> I don't believe this is at all certain, nor do I believe that
> it is desirable in general.  The whole point of having URNs is
> to permit some degree of common processing that is independent
> of namespace, including the ability to obtain metadata (if
> available) and/or access the resource (if the resource is
> available and the operation makes any sense for that resource).

Keith, I may even agree with what I think you are trying to say,
but I believe that statements based on "the whole point of
having URNs" really gets in our way at this point.   At least
one of the reasons for that is that I think it drives us
inevitably toward a conclusion that a "urn:" scheme was a
mistake and that, instead, "URN" should have been an abstract
category of URI, just like "URL" and schemes should have been
tied to classes of resolution (or non-resolution) approaches and
methods (or abstractions of them).  Then one could have really
interesting conversations about whether the set of "URLs" and
the set of "URNs" should be lexically distinguishable (and
distinguishable from "URC" and any other sets of URIs that might
show up in the future).    Unless we are prepared to suggest
deprecating the "urn:" scheme and starting over, let's not go
there.

The following is a lot more relevant, at least IMO...

> That said, neither do I want to force a "one size fits all"
> model on URN resolution.   I have several reasons for this,
> the most important probably being that such services need to
> be able to evolve over time, perhaps especially in the near
> term, and therefore it is necessary that it be possible to
> have different and even competing services.

Operationally and in terms of 2141bis, I think that leaves us in
exactly the same place, independent of our assumptions,
predictions, or religious beliefs about the future.  I think the
registrations of namespaces need to have the capability of
specifying separate resolution models even though I hope they
were evolve in similar ways.  You think there have to be
arrangements for different registration models for different
namespaces because, which you hope and expect to see
commonality, things might evolve in different ways, or new
technologies be introduced, in the future.  In practical terms
as applied to 2141bis, I don't see a difference.

>   But promoting
> the idea that resolution is inherently something for each
> namespace to determine on its own, IMO, would harm
> interoperability.   Sure, namespaces can offer any resolution
> services that they want for their URNs (or not), but so can
> anybody else.     And it's extremely important that this be
> possible.

Agreed, I think.  See above.

> (I also agree that trying to define a resolution service is
> beyond this group's charter, though I think it's reasonable to
> discuss such issues to the extent necessary to nail down text
> in 2141bis.)

Ok.  What else do you think we need to talk about to get
acceptable text into 2141bis in general and what is in 7.3.6 in
particular?

> Again, I think the mechanism for ensuring authenticity of
> metadata and/or resources associated with URNs cannot rely on
> "a tight and required binding to resolution services".
> Being able to determine authenticity of such metadata and
> resources is very important, but it's also very important that
> there not be a single point of control for access to resources
> named by URNs.   We don't want to build an information
> architecture that facilitates Orwellian "memory holes" - as
> the US government, as well as probably several others, would
> certainly like to do.

I'd like to skip the hyperbole, including claims about what
various governments would like to do (I don't see as much
intra-government homogeneity as I would infer from the above), I
don't think we disagree.   If you do, I'd appreciate your help
in understand how and why.

> And while I agree that IETF in the past has not had a stellar
> record at developing trust delegation systems, that's not a
> good argument for giving up.   IETF is currently revisiting
> those issues on several fronts, out of perhaps-reluctant
> necessity, due to the realization that both passive
> surveillance and active attacks on Internet traffic by various
> parties, some with near-limitless resources, are now
> commonplace and widespread.   We should all realize by now
> that simply trusting the authoritative servers for DNS or
> whatever, is now no longer sufficient.

Again, no disagreement at all.  I just don't consider resolving
the above issues to be critical path for the WG generally and
2141bis in particular.  I consider it an advantage because the
topics involve, to paraphrase an earlier on-list comment about
something else, can constitute a rathole of considerable size.

Also, FWIW, if I wanted to dive deeply into those issues, there
is a case to be made that the URN, and possibly the entire URI,
architecture are bad news because it tends to expose the
namespaces in which one is interested to a greater degree than
might be desired.

>> is a perfectly good URN.  It is about as persistent as
>> anything in western literary culture can be.  The reference is
>> unambiguous in the sense that likely users of the URN are
>> going to agree on what, conceptually, is being referenced.
>> It is definitely not an "indicator".  I don't think it is an
>> "abstract designator" either, but this example illustrates
>> why I'm a little hesitant about that terminology.   It is not
>> resolvable in any practical way and there are deep historical
>> questions (rooted, among other things, in assumptions about
>> texts that may have existed for a long time in oral form only
>> and even about whether "Homer" is a historical figure).
>> Whether such a URN is useful or not presumably depends on
>> what a possible registrant wants to use it for -- that isn't
>> a question on which the IETF should take a position or expect
>> folks to pay attention if we did.
 
> I probably agree with that, or at least agree that it should
> be reasonable to assign a URN to Homer's original text of the
> Illiad, even if such a document has never been found and is
> believed to no longer exist.   I certainly would not want to
> declare such uses out-of-scope.

Part of that comment is that there is no conclusive evidence
that such a text ever existed, at least in written form, and
some evidence to the contrary.   I hope that does not change
your answer.

best,
    john

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 May 2015 16:53:59 -0400

On 05/29/2015 02:49 PM, John C Klensin wrote:
> methods (or abstractions of them).

I don't think that makes sense.   What you seem to be saying is that 
there should be no effort to build a common framework for handling 
stable resource names, and that instead, each different type of stable 
resource name should have its own resolution protocols. This in turn 
would appear to make it likely that only a few different kinds of stable 
resource names would be supported by clients, and the organizations 
maintaining such resource names would have a tremendous degree of 
control over not only naming but also access to all resources named 
using their schemes.    And I don't see why anything that I said "drives 
us inevitably toward" such a conclusion.

Fortunately, we didn't go in that direction.
> were evolve in similar ways.

They can provide whatever resolution services they wish.  Nothing is 
stopping them.   I just don't want us to promote the idea that 
namespaces are somehow axiomatically either authoritative or sole 
sources for such information.   In general, they're not.   To the extent 
that this model makes sense for some URN namespaces of limited scope, 
this is a corner case, not the general case.

> You think there have to be

One difference is that namespaces should not be set up to be the 
gatekeepers for access to resources or metadata associated with their 
URNs.    Another difference is that evolution of resolution services 
should not be entirely up to namespaces.   Anyone should be able to 
provide resolution services.   Ideally, there would be a means of 
signing metadata, content, and/or public keys of resources so that the 
authenticity of a resource's or metadata's association with a URN could 
be verified independently of the resolution service used to obtain that 
metadata or access that resource.
> acceptable text into 2141bis in general and what is in 7.3.6 in

Very reasonable question.    I'll probably have to get back to you on 
that after the weekend.

> in understand how and why.

I don't know whether we disagree about that or not.   I'm just stating 
what I believe to be an important security concern.

(FWIW, I don't see that much intra-government homogeneity either. It 
just seemed better to say "the US government" than to name specific names.)

> something else, can constitute a rathole of considerable size.

Mostly agree.   I just think that for now we need to very carefully 
choose the words in the small portion of 2141bis that mentions resolution.

> namespaces in which one is interested to a greater degree than

Yet another reason why, even though there's nothing stopping people from 
setting them up, having namespaces be closely tied to any specific kind 
of content is not a good idea.

> some evidence to the contrary.   I hope that does not change

It does not.

Keith