Subject: [urn] generic/universal URN resolver

From: Andrew Newton <[email-masked]>
Date: Mon, 2 Nov 2015 21:21:11 -0500

The topic of a generic or universal URN resolver has come up in the
past, and I had thought we had brilliantly side-stepped the issue. But
it appears we have not.

It is my view that there is a difference between a generic or
universal URN resolver capable of resolving all types of URNs and a
standard for URNs capable of conveying different, definable components
of a URN to URN processing software where relying processes have URN
specific behavior. Or in other words, the development of a
specification for a generic URN resolver is not the same thing as
avoiding namespace specific URN syntax.

To my knowledge, there never has been a generic URN resolver. And
while that may have been a design goal at one time, the reality is
that URNs are a sufficiently large and broad concept that such a
critter is highly unlikely to ever exist. None of us can predict the
future, but I'm willing to bet cash money on this prediction.
Therefore I suggest we discontinue any focus on one.

However, it does seem worthwhile to have a specification where
namespace specific knowledge is not required to pull apart the
components of a URN. A URN parsing library should be able to provide
to client processes the various components of a URN, even though the
meaning of those components are only meaningful in the context of a
specific namespace or resource.

So here is a question to the working group. Does this distinction
define the correct goal (URN parsing) and non-goal (generic URN
resolver)?

-andy

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Nov 2015 22:39:06 -0500

--On Monday, November 02, 2015 21:21 -0500 Andrew Newton
<[email-masked]> wrote:

> The topic of a generic or universal URN resolver has come up
> in the past, and I had thought we had brilliantly side-stepped
> the issue. But it appears we have not.
> 
> universal URN resolver capable of resolving all types of URNs
> and a standard for URNs capable of conveying different,
> definable components of a URN to URN processing software where
> relying processes have URN specific behavior. Or in other
> words, the development of a specification for a generic URN
> resolver is not the same thing as avoiding namespace specific
> URN syntax.

Yes, exactly, although I would have added "namespace specific
semantic interpretations within the components of that syntax"
to your list of things we probably can't nail down and shouldn't
try.  Put a bit differently and picking up on your terminology
below, we can (and, IMO, should) be very clear about how to pull
apart the various pieces of URN syntax (specifically into the
NID, NSS, q-component, r-component, and f-component pieces
specified in 2141bis-14) but that we need to accept that there
will be namespace-specific syntax and semantic interpretations
within those pieces (including whether a given one of the
x-components is allowed and considered meaningful).   If we can
draw the boundaries there, I think we can succeed.   If we have
to specify very much about the interpretation semantics of the
NSS or the q-component or r-component pieces, I have almost the
same reaction you do to revisiting q-components and
r-components: I don't think the WG can survive such a process.

> To my knowledge, there never has been a generic URN resolver.
> And while that may have been a design goal at one time, the
> reality is that URNs are a sufficiently large and broad
> concept that such a critter is highly unlikely to ever exist.
> None of us can predict the future, but I'm willing to bet cash
> money on this prediction. Therefore I suggest we discontinue
> any focus on one.

Yes.  And thanks.

> components of a URN. A URN parsing library should be able to
> provide to client processes the various components of a URN,
> even though the meaning of those components are only
> meaningful in the context of a specific namespace or resource.

Yes.  That is consistent with the above and with what I believe
Peter and I have been trying to do (in our loosely coordinated
way) with 2141bis.  Again, if people find things in -14 that
seem insufficient to that goal, I wish they would point them out
quickly and ideally provide draft text.

> So here is a question to the working group. Does this
> distinction define the correct goal (URN parsing) and non-goal
> (generic URN resolver)?

My opinion is "yes", again with "URN parsing" interpreted as
breaking what 2141bis calls a "namestring" into the three
components of <assigned-name> and the q-, r-, and f-components.

     john

---

From: Keith Moore <[email-masked]>
Date: Tue, 3 Nov 2015 19:03:44 -0500

> Therefore I suggest we discontinue any focus on one.

Assuming I understand you correctly, I disagree in the strongest 
possible terms.  Extending URNs in such a way as to make development of 
generic URN handling tools infeasible would make URNs almost useless.   
I don't believe that is an acceptable outcome of this working group.   I 
also believe that any standards-track proposal with that likely result 
would grossly fail the "no known technical omissions" requirement of RFC 
2026.

> specific namespace or resource.

Parsing a URN is easy, but there's a lot more to this than parsing.

> define the correct goal (URN parsing) and non-goal (generic URN

Absolutely not.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 3 Nov 2015 19:21:13 -0500

On 11/02/2015 10:39 PM, John C Klensin wrote:
> within those pieces
I do accept that there will be some (hopefully few) of these, as a 
necessary evil.

> (including whether a given one of the
> x-components is allowed and considered meaningful).

I have yet to see a single justification for that, and as far as I can 
tell it makes no sense whatsoever.   Interpretation of q-component is 
entirely the purview of the resource named by the URN.  Interpretation 
of f-component is entirely defined by the media type of the resulting 
content.  Neither the namespace nor the resolution service has any 
business dictating or the interpretation or applicability of either 
one.   That would break relative references, it would also thwart URN 
interoperability.

> If we can

as far as I can tell, it's actually pretty simple:

1. interpretation of both f-components and q-components are out of scope 
for resolution services and namespaces.  full stop.
2. an IANA registry of r-component facets, with namespaces strongly 
discouraged from defining facet names that appear to be generic but are 
actually namespace-specific

Keitih

---

From: Andrew Newton <[email-masked]>
Date: Wed, 4 Nov 2015 15:04:28 -0500

On Tue, Nov 3, 2015 at 7:03 PM, Keith Moore <[email-masked]> wrote:
> Assuming I understand you correctly, I disagree in the strongest possible
> terms.  Extending URNs in such a way as to make development of generic URN
> handling tools infeasible would make URNs almost useless.

You have changed the terminology here. "generic URN handling tools"
and a generic URN resolver are not the same thing. The term you are
using does not necessarily include URN resolution. Note that I have
specifically said "resolver".

> I don't believe
> that is an acceptable outcome of this working group.   I also believe that
> any standards-track proposal with that likely result would grossly fail the
> "no known technical omissions" requirement of RFC 2026.

The complete sentence from 2026 is: "A Proposed Standard should have
no known technical omissions with respect to the requirements placed
upon it." (Also note that 2026 states that even this is not an
absolute).

The very fact that it is necessary to have this discussion is proof
that a generic URN resolver is not a requirement that has been placed
upon this working group by the IESG or previous IETF consensus. Even
if there were previous IETF consensus, the fact that the IETF has
ratified URNs that cannot resolve would show that the IETF consensus
changed.

To my knowledge this working group is not bound by any requirement for
a generic URN resolver, and the acceptance or rejection of that
requirement is a matter this working group may choose.

To the contrary, if your position is that a generic URN resolver is a
requirement and this working group puts forward a specification that
cannot resolve all URNs, that is a known technical omission.

It might be useful for you to define the specific operations upon ALL
URNs for which you believe a "generic URN handling tool" MUST be
capable. But you have clearly stated in other threads that you do not
believe resolution is one of them, as you have clearly noted that all
URNs are not resolvable.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 4 Nov 2015 15:10:51 -0500

> actually namespace-specific

This seems like a fine idea for the working group to consider. But it
does not guarantee resolution of all URN namespaces, nor does it
guarantee resolution of all URN namespaces that can be resolved. An
implementer cannot take the 2141bis RFC and be assured that whatever
new URN pops up in the future will be compatible with their URN
resolver. They must periodically check the IANA registry and add new
behavior to their software from time to time.

-andy

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Nov 2015 15:21:54 -0500

--On Wednesday, November 04, 2015 15:10 -0500 Andrew Newton
<[email-masked]> wrote:

>> 2. an IANA registry of r-component facets, with namespaces
>> strongly discouraged from defining facet names that appear to
>> be generic but are actually namespace-specific
> 
> This seems like a fine idea for the working group to consider.
> But it does not guarantee resolution of all URN namespaces,
> nor does it guarantee resolution of all URN namespaces that
> can be resolved. An implementer cannot take the 2141bis RFC
> and be assured that whatever new URN pops up in the future
> will be compatible with their URN resolver. They must
> periodically check the IANA registry and add new behavior to
> their software from time to time.

Andy, one addition to this.  I'm not quite sure what a
"r-component facet" is, but the proposal that started us down
the path toward separation of q-components and r-components was
one to require that URN <queries" be restricted to name-value
pairs and that a registry of those names be created to identify
ones with global (across-URN) meanings.  The WG didn't like that
idea at all (in retrospect, for good reason).   

It seems to me that going down the path toward the sort of
registry Keith suggests, one in which some "facet names" are
generic and in a registry and others are not, takes us back
around that loop again, even if it just applies to r-component
strings and not what we would consider today to be  both
r-components and q-components.   

In addition, in principle, we could simplify the spec somewhat
by (again) proposing and defining such global keywords and
eliminating the syntactic distinction between the two component
types.  I mention that, not to restart the separation argument
but to suggest it illustrates why a design conditioned on such a
registry -- one that I think essentially requires an implementer
to predict what facet names will be registering the future as a
condition for predictable operation -- is a non-starter.

best,
    john

---

From: Andrew Newton <[email-masked]>
Date: Wed, 4 Nov 2015 16:23:55 -0500

> idea at all (in retrospect, for good reason).

Thanks John. I had missed that aspect. And I'll have to defer to your
history as my mind has blocked the trauma of the rickety bridge that
has gotten here. :)

I think a better definition of "facet" with respect to r-components is
a good thing, along with some examples. As it stands, I don't know
what it means either.

> condition for predictable operation -- is a non-starter.

I think we are saying the same thing. The addition of an item in an
IANA protocol registry does not magically change software behavior. We
should probably have a better grasp of the use of this IANA protocol
registry before creating it.

-andy

---

From: Keith Moore <[email-masked]>
Date: Thu, 5 Nov 2015 23:31:54 -0500

On 11/04/2015 03:04 PM, Andrew Newton wrote:
> upon this working group by the IESG or previous IETF consensus.

No it is not.   All that this discussion demonstrates is that some 
people are either misinformed about URNs, or think they can redefine URN 
requirements that were settled by consensus twenty years ago, without a 
broad consensus to do so.

1. RFC 1737 was a consensus output of the URI working group.

2. RFC 1737 defined requirements for URNs, among which were:

    o Resolution: A URN will not impede resolution (translation into a
      URL, q.v.). To be more specific, for URNs that have corresponding
      URLs, there must be some feasible mechanism to translate a URN to a
      URL.

and

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

3. The URN working group that produced RFC 2141 was required to adhere 
to RFC 1737 as a condition of its charter.

4. Revisiting URN requirements is not within the scope of this working 
group according to its charter.

In particular, that charter states:

   For all document revisions, backward compatibility with previous
   URN-related RFCs will be retained.

> Even

No it would not, because:

a) There was never any requirement that every URN be resolvable (read 
the above requirements carefully, they do not go that far)
b) IETF does not ratify "URNs" it only approves namespaces
c) Even if IETF made a mistake in approving an URN namespace or two, 
that's not the same thing as revoking RFC 1737.

> requirement is a matter this working group may choose.

Strongly disagree.   This working group is NOT chartered to redefine 
URNs, and RFC 1737 is part of the definition of URNs.

> cannot resolve all URNs, that is a known technical omission.

Different WG participants might assign different meanings to "generic 
URN resolver".   But every time someone starts to explore what that 
might mean, some people insist that it can't be done (without providing 
any justification) and others insist that it's out of scope for the group.

> believe resolution is one of them, as you have clearly noted that all

To me, "generic" doesn't mean it applies to all URNs.  It means that any 
URN in any namespace can be made resolvable if its namespace is willing 
to advertise one or more resolution services for that namespace.   It 
means that there's a standard framework for parsing URNs, interpreting 
r-components, discovering resolution services, querying resolution 
services, and interpreting results of those queries, such that at least 
the most common operations (basically I2L and I2C with negotiation for 
which kind of metadata) can be supported for any URN for which they make 
sense.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 5 Nov 2015 23:32:20 -0500

On 11/04/2015 03:10 PM, Andrew Newton wrote:
> guarantee resolution of all URN namespaces that can be resolved.

I don't believe I ever claimed that it did.   Nor do I understand that 
as a requirement.

It was never a requirement that all namespaces be resolvable. (That's 
not even really a property of a namespace, since a namespace is 
potentially free to assign its names to any resources it wishes, whether 
or not they're resolvable.)

It was never a requirement to guarantee resolution of all URN namespaces 
that can be resolved.  (I don't even know what that means, since a 
namespace isn't resolvable anyway.   Some URNs within a namespace might 
be resolvable, but that's not the same thing.)

Basically 1737's requirements boil down to this:  If a set of URNs are 
used to name network-accessible resources that can be accessed via one 
or more URLs, it should be possible to implement a mechanism for those 
URN to be resolved.   (I'll infer a bit here: it clearly doesn't scale 
for every URN to have its own separate resolution mechanism that needs 
to be discovered - the implication is that there will be few enough such 
mechanisms for them to be widely implemented by clients.)

But it does not require that the namespace provide such a mechanism for 
the names that it assigns.

> An implementer cannot take the 2141bis RFC and be assured that whatever

I don't fundamentally disagree with that either.   In particular, the 
set of protocols used to resolve URNs and the formats of metadata 
returned from resolution services will necessarily evolve over time, and 
that means that multiple protocols and formats will inevitably 
coexist.   Implementations will need to be updated over time to 
accommodate new resolution protocols and metadata formats.

As for checking the IANA registry, many widely-used applications 
routinely consult various kinds of internet databases (including but not 
limited to DNS) and we don't consider that unusual or a showstopper.   
Nor do we consider it infeasible to distribute database updates as part 
of software updates (for example, the Olson timezone database is widely 
distributed in this manner).

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 5 Nov 2015 23:32:50 -0500

> idea at all (in retrospect, for good reason).

I didn't really like that idea either, partially because URL queries 
aren't required to conform to any syntax other than that specified by 
RFC 3986 or their individual URL scheme, and partially because trying to 
define a set of attribute names that won't conflict with any of the vast 
number of HTTP-accessible resources out there that have each been 
allowed to define their own sets of attribute names for over 20 years 
now, seems rather infeasible.   Having a separate, distinguished syntax 
for resolver parameters addresses that problem.

> r-components and q-components.

Fortunately no r-component facet names have been defined yet, so it's 
entirely feasible to reserve some space of r-component facet names for 
specific purposes, than it is to reserve some space of HTTP form 
attribute names for specific purposes at this late date. I don't see how 
it's significantly different from reserving IPv4 or IPv6 address 
prefixes for specific purposes.

> types.

That wouldn't really simplify things, it would just add complexity and 
make it somebody else's (bigger) problem.

(Of course, if the only goal were really to simplify things, we would 
just unplug all of our computers and dismantle the Internet. Yes, it 
would be simpler in some sense if we never built any resolution services 
or clients that could use them.   It's only because some of us believe 
that having resolvable long-term stable names would provide a benefit 
that's more than worth the cost and complexity that we're pursuing this 
effort.)

>   I mention that, not to restart the separation argument

I agree that requiring an implementer to predict what facet names will 
be registered in the future is a non-starter.   I would instead propose 
that all facet names require registration before use, and/or that there 
be a reserved space of facet names specifically for private use by 
namespaces.   (and perhaps others for private use by specific resolution 
protocols, or specific resolution service providers)

Again, this is really no different than several other attribute 
namespaces that we've been using for years.   Implementors of email user 
agents don't have to be able to predict every header field name that 
will exist in the future either.

Keith

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 6 Nov 2015 07:27:34 +0000

Hello, 

some comments below. 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Keith Moore
> Sent: 6. marraskuuta 2015 6:32
> To: Andrew Newton <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [urn] generic/universal URN resolver
> 
> >> discouraged from defining facet names that appear to be generic but
> >> are actually namespace-specific
> It was never a requirement that all namespaces be resolvable. (That's not even
> really a property of a namespace, since a namespace is potentially free to
> assign its names to any resources it wishes, whether or not they're resolvable.)

There are already two kinds of namespaces: ones which may be resolvable, and ones which a priori are not. 

We have agreed a long time ago that it is not a requirement that URNs must be resolvable. This applies to namespaces of the second type. Suppose someone registers a namespace for non-semantic ("dumb") identifier. The identifier itself contains no hint as regards where it can be resolved. If there is no centralized service to which all resolution requests can be directed, then these URNs are not really resolvable.

In practice: all ISSNs can only be resolved in the global ISSN database (or its mirror sites). If that databases is closed down, there is no single database out there that would cover all assigned ISSNs. Some services like OCLC's WorldCat would get close, but service would still be only partial.   

Of course, the best ISSN database and other bibliographic databases can do with ISSN resolution for now is to provide metadata about periodicals. If the URLs in metadata records are out of date, a user cannot find the periodical, so resolution may not provide useful results. 

And then there is urn:uuid namespace where, as far as I have understood correctly, it was never even an intention to provide resolution services. 
 
> It was never a requirement to guarantee resolution of all URN namespaces that
> can be resolved.  (I don't even know what that means, since a

IMO this WG does not need to discuss URN resolution after the basic decision we have taken years ago: one can register a namespace even if the URNs in it are not even intended to be resolvable.

> Basically 1737's requirements boil down to this:  If a set of URNs are used to
> name network-accessible resources that can be accessed via one or more URLs,
> it should be possible to implement a mechanism for those
> for every URN to have its own separate resolution mechanism that needs to be
> discovered - the implication is that there will be few enough such mechanisms
> for them to be widely implemented by clients.)

My personal opinion is that URNs which are a priori not actionable are not very useful. But there may be some specific circumstances in which they make sense, so therefore I did not insist on resolvability at least in theory. 

> But it does not require that the namespace provide such a mechanism for the
> names that it assigns.
> 
> > An implementer cannot take the 2141bis RFC and be assured that
> > whatever new URN pops up in the future will be compatible with their
> > URN resolver. They must periodically check the IANA registry and add
> > new behavior to their software from time to time.

Not every URN resolver will deal with every URN namespace. It is possible to build a hierarchical network of resolvers in which URN - URL mapping tables and other information about resolution is harvested to central resolvers which may then be able to deal with a larger number of URNs in certain namespaces and larger set of namespaces as well. But there are no plans to harvest all resolution information into a single system. And this would of course be a challenge for r-component based functionality which requires the resolvers to do something special.

If and when new r-component based functionality becomes available in one namespace, only resolvers which deal with URNs from that namespace need to do something. Resolvers which harvest mapping tables from native resolvers may omit URNs with r-component service parameters they do not know how to deal with, or harvest that data but pass any resolution requests to the resolver which "knows" what to do. 

For now, much of this functionality is missing from resolvers. And in my opinion it is not the task of this WG to deal with it, at least not now. The plan has to been to specify the syntax details of the r-component later, and after that we can start developing smart resolvers. That development could have started ages ago if URN syntax revision had been finished on schedule. 
  
> set of protocols used to resolve URNs and the formats of metadata returned
> from resolution services will necessarily evolve over time, and that means that
> multiple protocols and formats will inevitably

Yes. Technical infrastructure libraries etc. are using to manage digital documents is developing fast, and we need persistent identifiers which can adapt to this changing environment. It must be easy to specify new resolution services and service related parameters. Some of these services may be namespace specific at least to start with, but others, such as mapping of URNs to 1-n URLs will be generic. 

R- and q-components will play a major role in the process of making the resolvers smarter. If the only service resolvers can provide is to map URN and other PIDs to URLs, linked data will be much less linked and useful than it needs to be. 

Juha 

> As for checking the IANA registry, many widely-used applications routinely
> consult various kinds of internet databases (including but not
> Nor do we consider it infeasible to distribute database updates as part of
> software updates (for example, the Olson timezone database is widely
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Keith Moore <[email-masked]>
Date: Fri, 6 Nov 2015 08:11:28 -0500

> There are already two kinds of namespaces: ones which may be resolvable, and ones which a priori are not.

While I think we're in substantial agreement, I'm going to be a bit 
picky here, because very slight differences in wording, or in 
interpretations of the wording, can mean very different things in this 
discussion.   As I said above, I don't believe that this is inherently a 
property of a namespace, because a namespace can at any time choose to 
start assigning names according to different criteria than it has used 
in the past.

However, I agree that for any URN that is purely a unique string, one 
that isn't bound to anything at all, resolution (even if it were to to 
be implemented) would be a fairly meaningless operation.   The most that 
the resolution service could reasonably return is "this name isn't bound 
to anything".   (I do believe this would be useful, as this is a better 
result than simply "no information can be found".)

It occurs to me that a registry that advertises resolution services on a 
per-namespace basis could be designed in such a way as to allow a 
namespace to advertise that it has never assigned a URN to any resource  
- all of the URNs it has generated were merely for the purpose of being 
unique strings - and this would allow a resolution API to return the 
result "this URN isn't bound to anything".    And we could make entries 
in that registry for any URN namespaces (e.g. uuid) that are inherently 
nothing more than unique strings, and don't have an organization to make 
the entry on their behalf.

I also agree that for URNs that are bound to things that inherently 
aren't accessible over the network, resolution is limited to metadata.

I also agree that unless a namespace advertises one or more resolution 
services for that namespace, there will be no _authoritative_ resolution 
of the URNs from that namespace.

> We have agreed a long time ago that it is not a requirement that URNs must be resolvable.

And it was agreed 20 years ago that URNs must not impede resolution.   
But if you mean that "it is not a requirement to be able to resolve all 
URNs", I agree with that.

> This applies to namespaces of the second type. Suppose someone registers a namespace for non-semantic ("dumb") identifier. The identifier itself contains no hint as regards where it can be resolved. If there is no centralized service to which all resolution requests can be directed, then these URNs are not really resolvable.

Mostly agree, though see above.

> Of course, the best ISSN database and other bibliographic databases can do with ISSN resolution for now is to provide metadata about periodicals. If the URLs in metadata records are out of date, a…

Agree with all of the above.   Though even when there is a resolution 
service advertised by a namespace as being authoritative, there should 
be no requirement that the service provide complete coverage of all of 
the URNs which it has assigned.

> IMO this WG does not need to discuss URN resolution after the basic decision we have taken years ago: one can register a namespace even if the URNs in it are not even intended to be resolvable.

I'm not sure how to parse that sentence.     But I think we do need to 
discuss resolution at least to the extent that if some language in the 
2141bis draft impedes resolution, we need to be able to explain why this 
is the case and thus why that language needs to be altered or removed.   
(And when people make statements to the effect that generic resolution 
is impossible, as a justification for putting language in 2141bis that 
impede resolution, it becomes necessary to explain what is really meant 
by generic resolution, and/or to demonstrate that it is possible.)

> R- and q-components will play a major role in the process of making the resolvers smarter. If the only service resolvers can provide is to map URN and other PIDs to URLs, linked data will be much l…

I am still insisting that q-components should not be passed to 
resolvers, as they are entirely for consumption by the resource itself.
This is an important separation of function.   I don't understand why 
people claim that they should be passed to resolvers.

Keith

---

From: Andrew Newton <[email-masked]>
Date: Sat, 7 Nov 2015 06:21:34 +0900

There are differences in the two things we are talking about. I am
asking about the requirement of one single piece of software to
resolve all URNs. You are stating that all URNs must have a definable
resolution process if they are in a namespace that has resolution.

If you are claiming that we are creating a situation in which some
URNs will not have a definable resolution process (if they are meant
to be resolved), then I'd appreciate if you would point out the
specific aspects that cause this.

On Fri, Nov 6, 2015 at 1:31 PM, Keith Moore <[email-masked]> wrote:
> To me, "generic" doesn't mean it applies to all URNs.  It means that any URN
> in any namespace can be made resolvable if its namespace is willing to
> advertise one or more resolution services for that namespace.   It means
> that there's a standard framework for parsing URNs, interpreting
> r-components, discovering resolution services, querying resolution services,
> and interpreting results of those queries, such that at least the most
> common operations (basically I2L and I2C with negotiation for which kind of
> metadata) can be supported for any URN for which they make sense.

You lost me at interpreting r-components. Are you suggesting that your
proposed IANA protocol registry require IETF standards action to have
an entry added to it?

-andy

---

From: Andrew Newton <[email-masked]>
Date: Sat, 7 Nov 2015 06:27:37 +0900

On Fri, Nov 6, 2015 at 1:32 PM, Keith Moore <[email-masked]> wrote:
> specific purposes, than it is to reserve some space of HTTP form attribute
> names for specific purposes at this late date. I don't see how it's
> significantly different from reserving IPv4 or IPv6 address prefixes for
> specific purposes.

You really need to be much more specific about what a facet name is.
At this moment we can only take wild guesses about how you intend
r-components to be used and structured, how you intend the IANA
registry to be operated, etc... And asking the document authors to add
massive amounts of text on a hunch they might get it right is unfair
to them. So if you want this, "send text".

-andy

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Nov 2015 18:19:40 -0500

--On Friday, November 06, 2015 08:11 -0500 Keith Moore
<[email-masked]> wrote:

>...
> It occurs to me that a registry that advertises resolution
> services on a per-namespace basis could be designed in such a
> way as to allow a namespace to advertise that it has never
> assigned a URN to any resource  - all of the URNs it has
> generated were merely for the purpose of being unique strings
> - and this would allow a resolution API to return the result
> "this URN isn't bound to anything".    And we could make
> entries in that registry for any URN namespaces (e.g. uuid)
> that are inherently nothing more than unique strings, and
> don't have an organization to make the entry on their behalf.
> 
> I also agree that for URNs that are bound to things that
> inherently aren't accessible over the network, resolution is
> limited to metadata.
> 
> I also agree that unless a namespace advertises one or more
> resolution services for that namespace, there will be no
> _authoritative_ resolution of the URNs from that namespace.

Keith,

With Andy's recent comments very much in mind, allow me to add a
more specific observation:

If you are proposing changes to 2141bis (or any other active WG
document), please tell us exactly what you are proposing,
preferably in the form of specific text.   If you are proposing
new, separate, functionality, such as a new IANA registry with
different structure, contents, or usage (as I infer from the
first sentence above), then please write and post an I-D that
the WG can consider... starting with considering whether it
wants that I-D in its work program and, if so, where it fits in
that program and what, if anything, should be said about it in
2141bis.

Without more specifics (again, ideally in the form of proposed
text), I can't figure out enough about what it means for a
namespace (or registry) to "advertise a namespace" to construct
text.   I can hand wave with the best of them, but, if you are
going to object to any hand waving I try to do in that area (as
I think you, quite reasonably, would) then I don't want to waste
either of our time guessing at such text.

And, with apologies for being blunt, if you want the WG to wait
while things "occur to you" and you sort out possible designs,
please say that explicitly and propose a schedule so the WG can
decide whether it wants to wait.  If it does, we should probably
be quiet and let you push ahead.  If it does not, I hope you can
propose specific text about future work for 2141bis (or another
document) and get the WG to agree to that.

There are also a few things in this note and some others that
really do need to be nailed down for 2141bis unless hand waving
is acceptable.  For example, you wrote:

> I also agree that for URNs that are bound to things that
> inherently aren't accessible over the network, resolution is
> limited to metadata.

Now that is a very specific assertion ... or not, depending on
what metadata means (either generally of for a particular urn.   

As an only-slightly silly example, suppose one has a namespace
for "pirate treasure".  I've seen nothing so far that would
prohibit such a namespace and associated URN and if there were
to be such text in 2141bis-14, I'd argue it is a mistake.  That
hypothetical URN isn't likely to return gold doubloons, at least
until the Internet is upgraded to do matter transport.  My guess
is that 
    urn:piratetreasure:blackbeard
could "resolve" to "unknown location, lots of speculation".  I
think that is metadata, but I'm not sure.   On the other hand, 
    urn:piratetreasure:Whydah
might easily resolve to a map, to a list of museums at which
artifacts are being exhibited, a collection of photographs, etc.
If one assumes that none of those things are any more online
("on the net") than the ship's hull is, then which are data and
which are metadata (or whether they are all one or the other) is
a function of exactly how the namespace is defined and treated
and not, AFAICT, not some intrinsic property of the difference
between "data" and "metadata" (or those two and "object").

So, again, if you want something said along the lines of the
statement above in 2141bis, we need text that the WG can argue
about.  I also suggest that, unless you want to severely
constrain what sorts of URNs are possible (I prefer "constrain"
to "cripple", but the meanings in this context may be similar),
you not try defining the difference between "data" and
"metadata" in a namespace-independent way.

best,
     john