Subject: [urn] -14

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 1 Nov 2015 16:40:18 -0700

I've just submitted version -14, reflecting John's proposed text and 
list discussion since -13.

If you have comments, please send them along as soon as you can. Extra 
points if you send proposed text.

Let's get this done!

Peter

---

From: Melinda Shore <[email-masked]>
Date: Mon, 2 Nov 2015 08:49:33 +0900

Thank you, Peter!

All:  please review the document and get comments to the list.
Let's get this pushed along, and maybe, perhaps, we can get this
into wglc in 2015.

Thanks,

Melinda

---

From: Keith Moore <[email-masked]>
Date: Sun, 1 Nov 2015 22:15:48 -0500

> Let's get this pushed along, and maybe, perhaps, we can get this

When the few active participants on this list can't even agree on the 
purpose of URNs, pushing for WGLC seems very premature.

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 1 Nov 2015 20:26:21 -0700

> purpose of URNs, pushing for WGLC seems very premature.

If that's the case, we might as well close the WG now.

Perhaps I'm deluding myself, but I tend to think the disagreements here 
aren't as serious as they might first appear, and that participants are 
not all that far apart when it comes to the actual text of the spec.

Peter

---

From: Keith Moore <[email-masked]>
Date: Sun, 1 Nov 2015 22:38:26 -0500

>
> Perhaps I'm deluding myself, but I tend to think the disagreements 
> here aren't as serious as they might first appear, and that 
> participants are not all that far apart when it comes to the actual 
> text of the spec.

I suspect that the current text is very close to being what we need, but 
what's left unsaid or misstated by the current text (even if only 
slightly) is of huge importance.

I think we need to produce some detailed examples of how we expect URNs 
to work.    Maybe they don't end up in the document (or maybe in a 
separate informational document) but those examples might expose 
significant disagreements or ambiguities in 2141bis that we need to resolve.

Keith

---

From: Sean Leonard <[email-masked]>
Date: Mon, 2 Nov 2015 16:03:27 +0900

On Nov 2, 2015, at 12:38 PM, Keith Moore <[email-masked]> wrote:

>>  the disagreements here aren't as serious as they might first appear, and that participants are not all that far apart when it comes to the actual text of the spec.

I agree with this sentiment.

> 
> I suspect that the current text is very close to being what we need, but what's left unsaid or misstated by the current text (even if only slightly) is of huge importance.
> 
> I think we need to produce some detailed examples of how we expect URNs to work.

I also agree with this sentiment.

>    Maybe they don't end up in the document (or maybe in a separate informational document) but those examples might expose significant disagreements or ambiguities in 2141bis that we need to resolve.

I do not agree so much with this sentiment. I strongly propose that we use the WG Wiki:
http://trac.tools.ietf.org/wg/urnbis/trac/wiki

To record some specific detailed examples, as well as areas of significant disagreements or ambiguities.

In particular, though, I propose that we use the WG wiki to document agreements that this WG has reached historically, as a record of milestones of progress, and so that if people disagree, we can point to somewhere (other than the urnbis draft itself) on where are are with the status quo.

Sean

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Nov 2015 07:29:02 -0500

--On Sunday, November 01, 2015 22:38 -0500 Keith Moore
<[email-masked]> wrote:

>...
>> Perhaps I'm deluding myself, but I tend to think the
>> disagreements  here aren't as serious as they might first
>> appear, and that  participants are not all that far apart
>> when it comes to the actual  text of the spec.

Agreed.  These details are important, but I don't see much that
is insurmountable if we can stay focused.  On the other hand, I
would also have said that a year ago, which is one of the things
that makes part of this process so frustrating... and, I assume,
not just to me.

> I suspect that the current text is very close to being what we
> need, but what's left unsaid or misstated by the current text
> (even if only slightly) is of huge importance.

I mostly agree with that too, but I think we need to be careful
and reasonable.   Perfection is impossible and not every detail
is important (hugely or not) and I would hope that any "this
needs to be fully specified and/or fixed before the document(s)
can go into WGLC" statements would be accompanied by an
explanation for that particular case as to why.  In particular,
if there are things we are going to leave to the discretion and
needs of individual namespaces (I think, given the nature of
URNs, that is inevitable and consistent with 2141 and earlier
documents), then it is important to be clear about the boundary
but anything we say beyond that has to be in the form of
non-normative examples.

> I think we need to produce some detailed examples of how we

Following on the above, yes, but only if we can be very clear
that the set of examples is neither normative nor exhaustive.
I think that, if we get "comprehensive typology of URN
namespaces or their uses" into the critical path, the earlier
comments about just giving up probably apply.  I don't think
Keith was suggesting that, but the wording above might tend to
drift in that direction.

>    Maybe they don't end up in the
> document (or maybe in a separate informational document) but
> those examples might expose significant disagreements or
> ambiguities in 2141bis that we need to resolve.

Yes, but let's do it in I-D form or some other form that will
expire and be seen as non-normative if we don't decide to
publish it as a consensus document.  The problem with doing it
in a Wiki is the same as the problem with "tutorials" about a
standard that are produced by the body that produced the
standard: because they are almost inevitably easier to read than
the standard itself (if only because of the details that are
left out), they tend to become the standard in practice.  That,
in turn, leads to interoperability issues between
implementations of the standard and implementation of the
informal, supplementary, non-consensus materials.  Especially
with the combination of a Wiki and controversial issues, the
"winner" tends to be whomever has the most energy for the
longest time, not community rough consensus.

      john

---

From: Keith Moore <[email-masked]>
Date: Mon, 2 Nov 2015 08:11:44 -0500

> but anything we say beyond that has to be in the form of

It's that kind of language that makes me worry.  I am very skeptical 
that leaving things to "the discretion and needs of individual 
namespaces" is at all appropriate.   It is essential that clients be 
able to process URNs without having to know details about specific 
namespaces.   Saying we can leave things to namespace discretion seems 
basically like a failure to do our job in creating a standard.

I do accept that different resolution services will probably recognize 
somewhat different sets of r-parameter facets and offer somewhat 
different kinds of metadata, if for no other reason than that these need 
to be able to evolve over time.   But I don't think this is a 
namespace-specific attribute, but rather an attribute of the resolution 
service.

Can you cite examples of things that need to be left to namespace 
discretion?

> that the set of examples is neither normative nor exhaustive.

Agreed, and that's part of why I suggested that these go into a separate 
Informational document.   It's obvious to me at least that there's a 
tremendous amount of potential flexibility in how URNs are resolved to 
enable users to access resource content or metadata, and trying to pin 
all of that down is probably like commanding the tides to recede.    And 
yet, there does need to be some discipline and constraints in how URNs 
and their various components are used (at least, if we want clients to 
be able to use them in a repeatable/reliable fashion), and we don't seem 
to have made much progress at discovering what that discipline and those 
constraints should be.

> longest time, not community rough consensus.

I agree with not using a Wiki, for that and other reasons.   I would 
like to start with mailing list discussion and evolve it to an I-D.   Of 
course it won't be published as a WG document if WG consensus isn't 
reached.

Keith

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Nov 2015 10:37:42 -0500

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

>...
>> I mostly agree with that too, but I think we need to be
>> careful and reasonable.   Perfection is impossible and not
>> every detail is important (hugely or not) and I would hope
>> that any "this needs to be fully specified and/or fixed
>> before the document(s) can go into WGLC" statements would be
>> accompanied by an explanation for that particular case as to
>> why.  In particular, if there are things we are going to
>> leave to the discretion and needs of individual namespaces (I
>> think, given the nature of URNs, that is inevitable and
>> consistent with 2141 and earlier documents), then it is
>> important to be clear about the boundary but anything we say
>> beyond that has to be in the form of non-normative examples.
> 
> It's that kind of language that makes me worry.  I am very
> skeptical that leaving things to "the discretion and needs of
> individual namespaces" is at all appropriate.   It is
> essential that clients be able to process URNs without having
> to know details about specific namespaces.   Saying we can
> leave things to namespace discretion seems basically like a
> failure to do our job in creating a standard.

This is precisely the kind of disagreement (whether apparent or
real) that I think needs to be exposed, discussed, resolved, and
then taken sufficiently off the table that attempts to reopen it
are strongly resisted by the WG.   If we are to make progress,
that is true independent of which of us are correct.

Now, let me be sure that I understand what you are suggesting.
If a "client" has to be able to "process URNs without having to
know details about specific namespaces", that means to me that
one cannot have per-namespace "resolvers" or resolution
mechanisms, i.e., that, if any URN is resolvable, all URNs must
be, and that there must be a generic resolution mechanism that
works for all URNs and that, moreover, that there be no
namespace-specific resolution machinery to be applied for any
namespace after that generic resolution mechanism does its job.
That, in turn, suggests to me that, from the following
category-descriptions, one can have valid URNs in only one of
them, not all three (or others) (ignoring for the moment whether
I'm talking about the entire URN string (2141bis "namestring")
or what 2141bis-14 calls an "assigned-name"):

	(a) Pure identifiers that do not resolve at all, but are
	merely tested for string equality.
	
	(b) URNs that map into ("resolve to") some sort of URL.
	
	(c) URNs that identify a (presumably digital) object in
	some other way.  For example in that regard, assume a
	URN that names a particular text but, without embedding
	a DOI string in the URN namestring, resolves to a DOI.
	Whether that DOI is then made part of a URL (in doi.org
	or elsewhere) is not a URN definition problem.   Similar
	examples would apply to URNs that name or refer to
	library objects but that resolve, not to a URL but to an
	accession number or shelf location.

My impression was that the WG agreed to the validity of all of
those three casss as URNs long ago, at least for the second and
third probably about the time we decided that DDDS was _a_ way
to resolve _some_ URNs but not a necessary element of a generic
URN system.

However, one doesn't even need to look to 2141bis and history
since 2141 (May 1997) or 2483 (January 1999) to have that
per-namespace problem.

	urn:ISSN:1046-8188 (from RFC 3044 Section 3.1) treats the NSS
at the identifier within the ISSN namespace but

   urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637
(RFC 6963, Section 5) involves a "sub-namespace" that much be
interpreted differently at some point rather than viewing the
NSS as atomic.   Presumably urn:ISSN:foobar:9999-9999 would be
considered a syntax error.  At least something
namespace-specific would want to reject it rather than passing
it on to some resolution machinery.

Because of that, I think 2141 itself works iff one uses generic
URN processing to identify the NID and then passes the NSS off
to an NID-family-specific processor (I say "family" because I
don't believe we will have, or should have, separate processors
for each NID even though I expect the total number of processors
will be much larger than one).

Now, if you agree with the above, I've very confused about what
you are talking about or where the boundaries lie.  In
particular...

> I do accept that different resolution services will probably
> recognize somewhat different sets of r-parameter facets and
> offer somewhat different kinds of metadata, if for no other
> reason than that these need to be able to evolve over time.
> But I don't think this is a namespace-specific attribute, but
> rather an attribute of the resolution service.

Again, that completely confuses me, at least in part because I
think that a generic URN processor can be expected to do only
three things:

	(i) Parse the namestring, identifying the elements of
	<namestring> and <assigned-name>.[1]
	
	(ii) Try to find an appropriate resolution service based
	on the NID.  If it cannot find one, do something
	reasonable [2].
	
	(iii) If it can, identify a resolution service that it
	understands [3], pass the NSS, and any of q-component,
	r-component, and maybe f-component that are present, 
   to the resolution service [4].  

Note that the above implies that the semantics and within-string
syntax of r-component and the handling of q-component are mostly
the problem of the resolution service.  Because we expect the
resolution service to digest r-components, we don't need to be
as specific about its within-string syntax as we do about
q-component (or f-component), which, at least as I understand
our definitions so far, we expect to be passed more or less
intact from the resolution service.  

> Can you cite examples of things that need to be left to
> namespace discretion?

Whether the namespace is resolved at all.  Whether
sub-namespaces are allowed.  Whether q-component and/or
f-components are consider valid.  Whether r-components are
accepted and what syntax and semantics they have.

  best,
     john

[1] Given the way URIs are defined, this is actually a rather
difficult problem because, whether there are generic URI parsers
or not, there is really no such thing as a generic URI (or even
URN) resolver that can encounter and generically report error
states.  If I put "http:[[]]" into an href, any standardized
error-handling is part of the HTML spec (very much scheme and
content-specific) not part of either 3986 or, IIR, the http
spec.   I hope we don't have a URK in our future named "fail"
whose hier-part is unspecified but might be an error message or
code, which it would be one way to deal with putative URNs that
cannot be parsed.   Especially if we need to be as specific as I
gather you want (and as my instincts tell me will probably be
necessary), I don't see how to avoid saying something about this
in 2141bis but don't, at the moment, know what to say.

[2] This is obviously a mess.   It is the mess that NAPTR and
DDDS were intended to solve by creating a DNS-based indirection
mechanism for binding resolution mechanisms for NIDs, but that
has failed to achieve wide adoption and the WG (and the DDDS
specs themselves) have decided that not all URNs are required to
be bound to DDDS.  Maybe that was a mistake, but the horse has
left the barn and vanished over the horizon.  I'm sure, based on
experience, that "look the NID up in the IANA registry in real
time" is not going to be acceptable operationally (even if there
were no other issues).   The result is that I don't see any
alternative to doing some handwaving around "find a resolver
based on the NID and do something intelligent if you can't find
one" and then either assuming that "can't find resolver with a
reasonable amount of effort" means "this NID does not resolve"
or "need to return some sort of 'fail' indication".  That makes
me _very_ unhappy but, given where we have gotten, I'm having
trouble figuring out alternatives that do not require inventing
a somewhat more general and flexible successor to DDDS and
insisting that all URNs be able to use it.

[4] If we were modeling a process, rather than syntax and (at
least some) semantics, we could specify the difference between

  generic-engine CALLS NID-resolver(NSS, r-component)
    GETS BACK <string>
    CONSTRUCTS (string, decoded-q-component, f-component)
    and returns that to wherever it goes

and

  generic-engine CALLS NID-resolver(NSS, r-component,
       q-component, f-component)
    GETS BACK a string that includes q-component and 
       f-component as appropriate
    and returns that to wherever it goes

with "string" in both cases being more or less the hier-part of
a URL for case (b) (and I don't know how to think about (a) and
(c), much less others).

But we can't so, if we are are going to define a generic
resolution service, we are going to need to define what it can
return and probably the operations it performs to get there.  I
don't think we can do that for the reasons that make the three
different URN cases identified above as (a), (b), and (c) (and
others) important.

---

From: Sean Leonard <[email-masked]>
Date: Tue, 3 Nov 2015 07:17:56 +0900

On Nov 2, 2015, at 9:29 PM, John C Klensin <[email-masked]> wrote:

> The problem with doing it
> left out), they tend to become the standard in practice.

Then put a disclaimer at the top of the Wiki that this is just for brainstorming and discussion only, and delete the Wiki when done.

If the Wiki is easier to read than the standard document, that’s an indictment of the standard document. Don’t choose things because they are more difficult to use.

Look: the alternative is what is happening here: years and years of endless discussions by e-mail with various points brought up again or rehashed in variant form by different participants.

Sean

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 2 Nov 2015 15:28:30 -0700

On 11/2/15 3:17 PM, Sean Leonard wrote:
>> The problem with doing it in a Wiki is the same as the problem with
>> "tutorials" about a standard that are produced by the body that
>> produced the standard: because they are almost inevitably easier to
>> read than the standard itself (if only because of the details that
>> are left out), they tend to become the standard in practice.
>
> Then put a disclaimer at the top of the Wiki that this is just for
> brainstorming and discussion only, and delete the Wiki when done.
>
> If the Wiki is easier to read than the standard document, that’s an
> indictment of the standard document. Don’t choose things because they
> are more difficult to use.
>
> Look: the alternative is what is happening here: years and years of
> endless discussions by e-mail with various points brought up again or
> rehashed in variant form by different participants.

I don't think that using a different tool will magically help us through 
this impasse. Pointing to a wiki page isn't all that different from 
pointing to the list archive.

Peter

---

From: Sean Leonard <[email-masked]>
Date: Tue, 3 Nov 2015 08:01:02 +0900

> to resolve _some_ URNs but not a necessary element of a generic

I can’t speak about DDDS. But I think that (a), (b), and (c) are all valid URNs. No complaints about that model or what the WG already established.

Some resolutions will naturally be specific to and defined by the namespace (or sub-namespace, if so inclined to view things that way). For example:

urn:xmlns:foobar2015

is meant to represent an XML namespace. If resolved and dereferenced, it is supposed to always return an XML schema (.xsd, application/xml or text/xml), namely the XML schemas that are registered with IANA on a first-come, first-served basis.

Most resolutions, however, are not specific to or defined by the namespace. For <urn:isbn:9999-9999> or <urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>, they could be resolved in lots of ways (accession number, shelf location, Amazon.com product page, data: URI, abstract pointer to in-memory security object) and I believe that Keith’s essential points are that all of these resolutions are contextually valid and that namespaces such as isbn: and uuid: SHOULD NOT be read to restrict the resolution possibilities.

But what’s good for one set of identifiers may not be good for another set of identifiers. And my argument is that even though you could identify an XML namespace with urn:xmlns:foobar2015 and then resolve it into something utterly tangential to the original purpose (e.g., a picture of cats), there really is no functional value in doing so.

> NSS as atomic.

I object to this example on two grounds.

First of all, it *is* a sub-namespace. urn:ietf:params, urn:ietf:rfc, and urn:ietf:bcp, are sub-namespaces. A sub-namespace is a subset of a namespace.

But urn:isbn:817525 is also a sub-namespace. Anything that is a partial string is a sub-namespace because it divides the namespace. Whether those divisions have namespace-specific semantics is *defined by the namespace registration*. My point is that urn:ietf:par is a sub-namespace because it forecloses urn:ietf:pas or urn:ietf:pat. But it is not internally significant, in contrast to urn:ietf:params:, which is significant. In the case of urn:isbn:817525, that is a significant sub-namespace because 81 is the group ID and 7525 is the publisher ID. Therefore, everything starting with urn:ietf:817525 will be titles published by the same publisher.

A generic URN processor does not need to care about these internal divisions. An urn:isbn: specific processor might actually care.

Secondly, there is reasonable disagreement about whether SHA-1 (cryptographic) hashes can or should be sufficient as namespace identifiers, without any other guarantees about uniqueness beyond its mathematical processes. After trying to do certspec (draft-seantek-certspec) as urn:cert, I have given up on that approach.

> a URL for case (b) (and I don't know how to think about (a) and

The resolution model I am using/proposing is:

urn: URI gets parsed into NID, NSS, r-component, q-component, f-component
generic-engine CALLS resolver(NID, NSS, r-component, q-component):
 resolver calls resolver-for(NID)
  IF NID-specific resolver exists, then NID-resolver(NSS, r-component, q-component)
  ELSE <implementation-defined-resolver>(NID, NSS, r-component, q-component)

 => GETS BACK text/uri-list

client can choose which URIs to use and dereference. The text/uri-list only contains URI productions [RFC3986] (no relative-ref productions).

If URI does not have f-component in text/uri-list, the final URI (with fragment) is the URI in the text/uri-list and the fragment that is the f-component of the original urn: URI.
If URI has f-component in text/uri-list, the final URI (with fragment) is undefined.

As I have stated before, I have proposed eliminating q-component, making everything r-component. In the algorithm above all functions take (r-component, q-component) together, and return URIs that have query components. That is the logical premise on why separating r-component and q-component isn’t necessary.

Actually, I have proposed:

urn: URI gets parsed into NID, NSS, r-service-component, r-authority-component, r-params-component, f-component
generic-engine CALLS resolver(NID, NSS, r-service-component, r-authority-component, r-params-component):
 resolver calls resolver-at(r-authority-component)
  IF EXISTS, THEN resolver-at-authority(NID, NSS, r-service-component, r-params-component)
  ELSE:
   resolver calls resolver-for-service(NID, r-service-component)
    IF EXISTS, THEN service-resolver(NID, NSS, r-params-component)
    ELSE:
     resolver calls resolver-for(NID)
      IF NID-specific resolver exists, then NID-resolver(NSS)
      ELSE <implementation-defined-resolver>(NID, NSS)

 => GETS BACK text/uri-list

(Note that in this proposal, r-params-component has no semantics apart from what r-service-component provides.)

Sean

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Nov 2015 20:42:25 -0500

--On Monday, November 02, 2015 15:28 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>>> The problem with doing it in a Wiki is the same as the
>>> problem with "tutorials" about a standard that are produced
>>> by the body that produced the standard: because they are
>>> almost inevitably easier to read than the standard itself
>>> (if only because of the details that are left out), they
>>> tend to become the standard in practice.
>> 
>> Then put a disclaimer at the top of the Wiki that this is
>> just for brainstorming and discussion only, and delete the
>> Wiki when done.
>> 
>> If the Wiki is easier to read than the standard document,
>> that's an indictment of the standard document. Don't
>> choose things because they are more difficult to use.

No, it is at least as often the result of the tutorial making
simplifying assumptions or leaving things out while the standard
really has to cover all of the cases.

>> Look: the alternative is what is happening here: years and
>> years of endless discussions by e-mail with various points
>> brought up again or rehashed in variant form by different
>> participants.

> I don't think that using a different tool will magically help
> us through this impasse. Pointing to a wiki page isn't all
> that different from pointing to the list archive.

Mostly agreed.  To clarify my concern, had Sean said "issue
tracker" I wouldn't have objected significantly.  My concern
about a Wiki page is almost exactly the same as my objection to
pointing to the list archive: neither is authoritative in itself
and both can be taken over by anyone with a lot of energy and
time on their hands (whether long-lived or not).  While either
can provide evidence that something was discussed, neither
provides ready organization of material in a way that highlights
what issues have been closed out and which ones are still being
actively discussed or, worse, had the discussions fizzle out
without resolution but left in a state where it is perfectly
reasonable to bring them up again and start over.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Nov 2015 21:29:28 -0500

Sean,

I think, modulo some ways of thinking about the issue and
consequent terminology, we may be in agreement with each other
after all... but not in agreement with Keith if I correctly
understand him.  Specifically...

--On Tuesday, November 03, 2015 08:01 +0900 Sean Leonard
<[email-masked]> wrote:

>...
>> That, in turn, suggests to me that,
>> from the following category-descriptions, one can have valid
>> URNs in only one of them, not all three (or others) (ignoring
>> for the moment whether I'm talking about the entire URN
>> string (2141bis "namestring") or what 2141bis-14 calls an
>> "assigned-name"):
>> 
 
> I can't speak about DDDS. But I think that (a), (b), and (c)
> are all valid URNs. No complaints about that model or what the
> WG already established.

Good. Agreed there.  
 
> Some resolutions will naturally be specific to and defined by
> the namespace (or sub-namespace, if so inclined to view things
> that way). For example:
> 
> urn:xmlns:foobar2015
> 
> is meant to represent an XML namespace. If resolved and
> dereferenced, it is supposed to always return an XML schema
> (.xsd, application/xml or text/xml), namely the XML schemas
> that are registered with IANA on a first-come, first-served
> basis.

Ok.

> Most resolutions, however, are not specific to or defined by
> the namespace. For <urn:isbn:9999-9999> or
> <urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>, they could be
> resolved in lots of ways (accession number, shelf location,
> Amazon.com product page, data: URI, abstract pointer to
> in-memory security object) and I believe that Keith's
> essential points are that all of these resolutions are
> contextually valid and that namespaces such as isbn: and uuid:
> SHOULD NOT be read to restrict the resolution possibilities.

I think we need to hear from Keith because I've understood some
of his comments as wanting to prohibit resolutions that are
namespace-specific.

> But what's good for one set of identifiers may not be good
> for another set of identifiers. And my argument is that even
> though you could identify an XML namespace with
> urn:xmlns:foobar2015 and then resolve it into something
> utterly tangential to the original purpose (e.g., a picture of
> cats), there really is no functional value in doing so.

Ok.

> First of all, it *is* a sub-namespace. urn:ietf:params,
> urn:ietf:rfc, and urn:ietf:bcp, are sub-namespaces. A
> sub-namespace is a subset of a namespace.

> But urn:isbn:817525 is also a sub-namespace. Anything that is
> a partial string is a sub-namespace because it divides the
> namespace. Whether those divisions have namespace-specific
> semantics is *defined by the namespace registration*. My point
> is that urn:ietf:par is a sub-namespace because it forecloses
> urn:ietf:pas or urn:ietf:pat. But it is not internally
> significant, in contrast to urn:ietf:params:, which is
> significant. In the case of urn:isbn:817525, that is a
> significant sub-namespace because 81 is the group ID and 7525
> is the publisher ID. Therefore, everything starting with
> urn:ietf:817525 will be titles published by the same publisher.

I was trying to make a slightly different point about the
difference between dividing the namespace into partitions that
had their own rules about the rest of the hier-part of the URI
versus single-element partitions.  But I'm ok with your
definition too -- please suggest specific text for 2141bis.

> A generic URN processor does not need to care about these
> internal divisions. An urn:isbn: specific processor might
> actually care.

Yes, I hope.

> urn: URI gets parsed into NID, NSS, r-component, q-component,
> f-component generic-engine CALLS resolver(NID, NSS,
> r-component, q-component):  resolver calls resolver-for(NID)
>   IF NID-specific resolver exists, then NID-resolver(NSS,
> r-component, q-component)   ELSE
> <implementation-defined-resolver>(NID, NSS, r-component,
> q-component)
> 

Quibble:  If "text" is interpreted broadly, then "uri-list" is
just a subset and should not be an "or"-type conditino (or do I
misunderstand your notation as ABNF-like?).   If "text" is
interpreted narrowly, then I think the above implies that there
are two sorts of URNs (whether NID-specific resolvers exist or
not): those that, when resolved, return text and those that,
when resolved, return one or more URIs.  That excludes both
those that don't resolve and those that resolve to something
other than URI(s) or text.

More important, while it is possible to make a clear statement
about whether the resolver in "resolver(NID, NSS, r-component,
q-component):" knows about a particular NID-specific resolver or
not, making a statement about whether or not such a resolver
exists requires a universal resolver-finder (aka a universal
NID-> resolver mapper) from which a negative result implies "no
NID-specific resolver exists".  

Taking the DDDS and URC concepts up tens of thousands of meters
(perhaps high enough that their originators would not recognize
them because I'm about to suggest something with with they might
disagree), the idea was precisely to have a universal
resolver-finder: one could get a URN, look the NID up in the
DNS, and get back either one or more pointers to resolvers with
preferences, structure, and relevant properties (providing a
reliable existence test) or fail (with whatever implications
that had).   But, for better or worse, while URNs have caught
on, neither DDDS nor URCs have seen enough adoption for use with
URNs to be relevant as candidate universal-anything.

> client can choose which URIs to use and dereference. The
> text/uri-list only contains URI productions [RFC3986] (no
> relative-ref productions).

I'm happy to see you prohibiting relative-refs (and hope we
never have to revisit that topic), but, again, the apparent
restriction to URNs that resolve and resolve to URIs is
troubling... and appears to me to contradict your acceptance of
all of my (a)...(c) as valid.

> If URI does not have f-component in text/uri-list, the final
> URI (with fragment) is the URI in the text/uri-list and the
> fragment that is the f-component of the original urn: URI. If
> URI has f-component in text/uri-list, the final URI (with
> fragment) is undefined.

Not sure I understand this.  I would have guessed you were
heading toward exactly the opposite... unless you mean to say
that, unless the resolution mechanism knows what to do with
fragments, the fragment applies to the URN-string and not to the
result.   If the latter is what you intend, people who claim to
be experts on 3986 have claimed it violates that spec because
that spec requires that fragments belong to the finally-resolved
object (presumably not even the URI but the object located by
that URI).

> As I have stated before, I have proposed eliminating
> q-component, making everything r-component. In the algorithm
> above all functions take (r-component, q-component) together,
> and return URIs that have query components. That is the
> logical premise on why separating r-component and q-component
> isn't necessary.

See above with regard to URNs that do not resolve to URIs and my
prior note about other sorts of requirements.

> urn: URI gets parsed into NID, NSS, r-service-component,
> r-authority-component, r-params-component, f-component
> generic-engine CALLS resolver(NID, NSS, r-service-component,
> r-authority-component, r-params-component):  resolver calls
> resolver-at(r-authority-component)
>   IF EXISTS, THEN resolver-at-authority(NID, NSS,
> r-service-component, r-params-component)   ELSE:
>    resolver calls resolver-for-service(NID,
> r-service-component)     IF EXISTS, THEN service-resolver(NID,
> NSS, r-params-component)     ELSE:
> (Note that in this proposal, r-params-component has no
> semantics apart from what r-service-component provides.)

And that, fwiw, takes us even further down the path to which I
understand Keith is objecting: a lot of namespace-specific
syntax and semantics.  

We've also been there a very long time ago: the syntax models
were different, but I think that, functionally, the idea of
separating information or specifications about the resolver (or
resolver service), from information or specifications for the
resolver and authority, from parameter information to be passed
to the resolver (which might, in turn, include things that a
resolver would pass to an object or included in an output URI)
was present in the very first "structure the query and reserve
some sets of keywords" ideas that I sketched out (with a lot of
help from Juha) in around the IETF 85 timeframe, well prior to
Peter's suggestion of q-components and r-components.  That idea
of forcing query syntax for all URNs (that used them at all)
into name=value pairs and then taking advantage of clusters of
reserved name keywords was, in retrospect, not a good idea, but
the intent was, if I understand you, very similar to where you
are trying to go with the above breakdown.  Another idea I
thought we had closed out.

best,
    john

---

From: Keith Moore <[email-masked]>
Date: Tue, 3 Nov 2015 01:39:37 -0500

> that is true independent of which of us are correct.

Naming is inherently a difficult topic to discuss because (as computer 
scientists like to say) all problems can be solved by adding another 
layer of indirection.  It follows that any time someone proposes a new 
kind of name, particularly something as vaguely defined as "uniform 
resource name", anyone can imagine his particular problem being 
addressed by that naming and indirection scheme.

What seems to have happened for the entire history of URN discussions is 
that different participants each imagined URNs addressing the particular 
problem that he or she wanted to solve. As long as the URN definition 
focused entirely on syntax and "persistence" (vaguely defined), the 
conflicts between those goals were not exposed.   But as soon as we talk 
about resolution, the conflicts rear their ugly heads.   Some would like 
to finesse those conflicts by simply declaring resolution a 
namespace-dependent behavior.   I don't think that accomplishes anything 
because it doesn't facilitate interoperability.   If we can't define URN 
standards with sufficient precision to permit interoperability, what's 
the point of this effort?   I believe that we can do so, otherwise I 
wouldn't be investing time in this.

I should define what I mean by interoperability in this space.   A few 
things that immediately come to mind:

a) interoperability across namespaces - a client that supports 
operations on URNs should be able to support those operations for URNs 
of any namespace, as long as resolution services for the namespace 
adhere to one of a hopefully-small number of standards, and those 
resolution services are advertised and accessible to the client.

b) interoperability across clients - if two standards-conforming clients 
both support URNs, they should behave similarly when given the same URN 
and the same request for use of that URN (whether specified in the 
r-component of that URN, by context, or by some other means).

c) interoperability across resolution services - it should be possible 
to design a resolution service protocol that serves the needs of most if 
not all NIDs, and also possible to implement a server for that protocol 
that serves the needs of most if not all NIDs.

This, to me, implies that namespace-specific behavior should be kept to 
a minimum, or at least, that it should be possible for a client to 
implement common operations without relying on either specific knowledge 
of namespaces or nonstandard features of resolution services.   If there 
are additional operations that are possible by exploiting such 
namespace-specific knowledge or nonstandard features, that's not a 
catastrophe especially if it there is a path that facilitates 
standardization of the necessary features.

> namespace after that generic resolution mechanism does its job.

I don't believe that.   In particular, I expect to have a DDDS-like 
database, that is distributed by various means (not necessarily or 
specifically DNS), that advertises (namespace-id, protocol, service-URL) 
tuples, where protocol is an IANA-registered URN resolution protocol 
identifier, and service-URL specifies how to contact the resolution 
service (the details can be protocol-specific).    If DDDS is 
insufficient for this, replace it.   But even if DDDS has some specific 
flaws, the core idea of distributing this database over the network is 
sound.

(And maybe we need those tuples to be slightly more elaborate, or to be 
a different data structure, in order to facilitate earlier matching of 
resolution services with the assigned portion of URNs and the requested 
services.  So this is more of a concept than a proposal.  I'm trying to 
avoid having to draft protocol specifications for both the database and 
the resolution services just to answer this email.)

> them, not all three (or others)

I don't believe this either.   A resolution service advertised by the 
above means should be able to return both URLs of resource locations 
(when applicable) and various kinds of metadata about the resource (when 
applicable).

> to resolve _some_ URNs but not a necessary element of a generic

Well, of course _some_ URNs aren't resolvable, or even intended to be 
resolvable.   So any time you ask a resolution service about a 
particular URN, one of the potential answers can always be "I don't know 
anything about that URN".   The existence of a resolution service for a 
namespace doesn't assure that all URNs from that namespace are resolvable.

> it on to some resolution machinery.

URNs namespaces have always been able to have structure within the 
NSS.   Also, each namespace has always been able to define its own 
particular syntax for its NSSs, and also particular equivalence rules 
for its NSSs.    I'm not proposing to change those decisions.

But it's not strictly necessary to advertise each namespace's structure, 
syntax, and equivalence rules to every client.  If a client queries a 
resolution service about a URN that happens to be invalid, the 
resolution service can say "I don't know anything about that URN".  Or 
it can say "that URN is malformed" if it knows enough to say that.   Or 
it can say "I can't answer your query, but I can refer your query to 
resolution service X which should have specific information about that 
URN". Similarly, a client could ask a resolution service whether two 
URNs from the same namespace were equivalent according to that 
namespace's rules.

As an optimization, some information about the structure of an NSS or 
how its queries are delegated, or the equivalence rules for a namespace 
could be advertised by some means.   This might reduce load on the 
resolution servers.   In the 1990s, we tried using regular expression 
rewrite rules to advertise those sorts of things; today we might try a 
different approach.  Worst case, the namespace database could advertise 
a separate javascript library for each namespace that could be called to 
pick apart delegation structure and/or determine equivalence.   It's not 
my favorite approach (and might even have more pitfalls than NAPTR 
records) but I'm open to considering different ways of doing it.

> will be much larger than one).

I hope the total number of resolution protocols will be small, though I 
never expect it to be one.   There can of course be a great many 
resolution services, both for redundancy and to serve multiple NIDs or 
subspaces within an NID.

>     to the resolution service [4].

I disagree that these are the only things that a generic URN client can 
be expected to do.   I agree that (i) and (ii) are reasonable 
expectations.  Beyond those things, I think a generic URN client should 
be able to

(iv) request URLs that represent locations of the resource named by the 
URN (which will be returned by the resolution service only if the 
request is applicable to that kind of resource, the resolution service 
has the information, etc.)
(v) obtain the content of the resource named by the URN (again, when 
applicable for the resource named by the URN, when a resolution service 
has that information).
(vi) learn about the kinds of metadata that are available for that URN
(vii) obtain any specific kind of metadata that is available for the URN

This implies that the client needs to be able to parse the r-component 
to determine the type of service being requested, as well as any 
constraints that the r-component imposes on resource content.  It's also 
possible to have a conflict between a service requested in an 
r-component and the service that's implied by the context in which the 
URN appears, so clients may need to detect some of those conflicts.

I also disagree significantly about (iii).    Neither the q-component 
nor the f-component should be passed to a resolution service UNLESS, 
perhaps, the resolution service is being requested to return the 
resource content - and even then, passing the f-component is dubious.   
You really don't want the resolution service trying to interpret 
q-component or f-component.   It strikes me as the worst kind of 
layering violation, because it blurs an otherwise clean separation 
between the responsibilities of a URN namespace and the responsibilities 
of the resource owner/maintainer.   (I'm also skeptical that resolution 
services should ever be entrusted to return resource content, though I 
recognize that there are probably corner cases for which this makes sense.)

> the problem of the resolution service.
r-component - mostly but (unfortunately) not entirely.
q-component - it's not for the resolution service at all, but 
exclusively for use by the named resource.

> Because we expect the

I believe we do need to be somewhat specific about r-components because 
clients will need to digest them to some degree.
q-components and f-components should never be passed to the resolution 
service.

> Whether the namespace is resolved at all.

I think I see your point, though I believe private "resolution" services 
will be very important.   (Call them something other than resolution 
services if you want, but they should support the same protocols and 
operations.)   So the namespace can decide whether or not it wants to 
advertise "authoritative" resolution services, but it can't forbid 
private resolution.

> Whether sub-namespaces are allowed.

Sure, each namespace determines the structure of its NSS (including 
whether there is any).     Though I find myself wondering whether you're 
talking about NSS structure or delegation structure, which don't have to 
be along the same lines.

> Whether q-component and/or f-components are consider valid.

Disagree.   Whether q-component is valid depends on the type of resource 
being named and/or the protocol being used to access it. A namespace can 
elect to not assign names to any resources for which a q-component could 
possibly be valid (e.g. it could only assign names to paper books or 
physical sound recording media), or it could elect to not return any 
URLs which support query syntax.   But the meaning of the q-component is 
namespace independent, and it's important that this be made clear.

Similarly, the meaning of the f-component is entirely dependent on the 
media type of the resource and the content itself, and is not within the 
purview of the namespace to define.   Even if a namespace refuses to 
assign any of its names to any resources that contain fragment 
identifiers, there are fragments that are meaningful even in the absence 
of fragment identifiers in the resource content. For better or worse, 
this is the web architecture, and we aren't going to change that.

> Whether r-components are accepted and what syntax and semantics they have.

Disagree.  R-components need to be standardized, at least in broad 
terms, because clients need to be able to interpret them to some 
degree.  Furthermore, it appears that clients may need to be able to add 
r-components to URNs in order to request the services that they need 
(e.g. to get resource content or URLs or metadata) in the absence of an 
explicit request in the r-component.   And even though there might 
inevitably be a need for some namespace-specific requests that can be 
included in an r-component, resolution services will need to support a 
"common core" of r-component requests and semantics.

> in 2141bis but don't, at the moment, know what to say.

I'm not sure what you're saying here.   A URI parser might not be able 
to detect every possible kind of syntax error in a URI, but it can 
certainly detect some kinds of errors.  That parser can do no more (and 
should do no less) than to pass the error indication to its caller.   
What the caller does with that error is up to either the protocol 
specification being implemented by that caller, or to the implementation 
itself.   If some kinds of syntax errors effectively get interpreted by 
the caller as "resource not found", that's perhaps unfortunate, but it 
shouldn't preclude a parser reporting more precise errors just in case 
some caller will handle them intelligently.

Anyway, having written generic URI parsers that seemed to be sufficient 
to the task, I don't really see the problem here.

> left the barn and vanished over the horizon.
Even when DDDS was being hashed out, I don't recall anyone who expected 
all URNs to be required to be bound to DDDS.   It wasn't a mistake, it 
was simply a consequence of other decisions and painfully-acquired 
understanding, e.g. (a) URNs weren't only to be used for 
network-accessible resources; (b) even among network-accessible 
resources, there would always be URNs that you couldn't resolve without 
access rights (and some for which the existence of the resource wouldn't 
even be acknowledged without access rights -- if I recall correctly Ron 
Daniel argued this quite convincingly); (c) some URN namespaces which we 
thought desirable simply didn't lend themselves to centralized 
collection of either locations or metadata.   Also, many of us realized 
that DDDS was more of a proof-of-concept than anything else.  We hoped 
we could get something deployed enough to show what could be done with 
URNs even though we realized that if it were successful, it would have 
to either evolve or be replaced.

Also, even though the DNS realization of DDDS was the most obvious one, 
DDDS is not and was not intended to be specific to DNS.

>   I'm sure, based on
> were no other issues).

Well, no, not if we're using the current IANA servers that are only 
provisioned and maintained according to current expectations.   But we 
should all know better than to assume that.   I imagine that IANA would 
maintain the registry but not run the equivalent of the root servers for 
real-time lookup of NID space.   There are other ways of distributing 
that information than having IANA provide the service directly.   For 
example, it could outsource that via a large-scale DNS service provider 
if DNS were still used to advertise that information (which is perhaps 
not the best possible way, but certainly not the worst, and probably can 
be made sufficient). Alternatively, it could provide the top-level 
NID-to-service mapping information to the public on a rate-limited basis 
- anyone could get the information but the response would be slow enough 
that no client implementation would want to use it to do the lookup in 
real time. Publishers of software using URNs could obtain the 
information and distribute the information to their customers via normal 
software update channels.

I'm not saying I have the best answer right off the bat.  I am saying 
that arguments of the form "DDDS failed, therefore no net-based 
distribution of the NID mapping information can work" don't seem to have 
much merit.   At the very least, they need more detail and/or supporting 
evidence to be convincing.

> The result is that I don't see any

For reasons alluded to above, failure will always be a possible outcome 
where URN lookup is concerned.   I don't know why that should bother us, 
because while we expected that URNs could be used to name (almost) 
anything, we never expected to be able to build an oracle that could 
find every resource that could possibly be named.

So: general and flexible successor to DDDS - yes; insisting that all 
URNs be able to use it - no.  Maybe insisting that it be potentially 
applicable to most namespaces is a reasonable goal, but we can't force 
namespaces to operate or advertise resolution services or even recommend 
some services operated by others.   And even if every applicable 
namespace operated a resolution service, they won't necessarily be able 
to populate their services with information about every URN assigned 
under their namespace (again, because of confidentiality requirements).

> different URN cases identified above as (a), (b), and (c) (and

I don't see the problem.   I think the NID-resolver gets called with the 
assigned-portion of the URN + the r-component, plus perhaps some 
additional client-supplied parameters indicating what the client wants 
and/or what protocol(s) and result data models the client supports (or 
maybe the client modifies the r-component to include its request).   I 
think the NID-resolver returns either:
- an error indication,
- a redirect,
- one of the types of result documents expected/requested by the client, 
which depending on the request might be a list of URLs, or a set of 
metadata,
- or maybe even the resource content itself (though maybe that's a bad 
idea).

So to me the resolution service is fairly simple in concept and can be 
defined as some HTTP FORM parameters:
?urn=urn:example:foo??some-r-component&request_type=xxx&result_types=(aaa,bbb,ccc)
Of course, working out the details of the result documents and how the 
various kinds of results relate to one another is a huge task, though I 
expect that librarians and archivists are well along this path 
already.   IETF will do well enough to establish a protocol framework, 
some basic request types, an IANA registry for result types, a generic 
syntax for r-components, and an IANA registry for r-component facet names.

Defining client behavior is a bit trickier, because the client will need 
to handle several different scenarios in order to do what the user or 
requesting resource wants.   To get resource content it might need to 
consult multiple resolution services, follow redirects, first get a list 
of URLs and then try to find one of those that satisfies its selection 
criteria (French language, PDF format).    It might find that the 
requested resource isn't available but there is a related resource that 
is available (later version, HTML format instead), and determine whether 
that resource is acceptable.   In some cases it can ask the user; in 
other cases it will have to decide based on predetermined preferences 
and/or heuristics.

Keith

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Nov 2015 05:29:07 -0500

--On Tuesday, November 03, 2015 01:39 -0500 Keith Moore
<[email-masked]> wrote:

>>>> leave to the discretion and needs of individual namespaces
>>>> (I think, given the nature of URNs, that is inevitable and
>> This is precisely the kind of disagreement (whether apparent
>> or real) that I think needs to be exposed, discussed,
>> resolved, and then taken sufficiently off the table that
>> attempts to reopen it are strongly resisted by the WG.   If
>> we are to make progress, that is true independent of which of
>> us are correct.
> 
> Naming is inherently a difficult topic to discuss because (as
> computer scientists like to say) all problems can be solved by
> adding another layer of indirection.  It follows that any time
> someone proposes a new kind of name, particularly something as
> vaguely defined as "uniform resource name", anyone can imagine
> his particular problem being addressed by that naming and
> indirection scheme.
>...

Keith,

I found this very helpful in understanding what you are asking
for.  Rather than my responding with yet more over-long text
now, could you read Andy's most recent text and respond to that
as well?  I'd like to see if we (all three of us) can converge
by trying to separate your comments/requests into things that
fit within the scope of that note and things that he suggests
leaving out, but can't reasonably do that until I understand if
you accept his general principles.  If you do not, I should
probably stop adding long notes to the conversation until you
and he sort that out.

As a preview, I completely agree with your initial comments
about naming and the history of URNs and actually think I wrote
very similar paragraphs in the past.  There are other places
where I think we appear to disagree only because I made what I
thought were general comments or examples that I considered
non-comprehensive that you apparently interpreted as a
comprehensive listing and responded on that basis.  That sort of
difference should be easily straightened out and resolved.  For
example, you wrote

> In particular, I expect to have a DDDS-like database, that is
> distributed by various means (not necessarily or specifically
> DNS), that advertises (namespace-id, protocol, service-URL)
> tuples, where protocol is an IANA-registered URN resolution
> protocol identifier, and service-URL specifies how to contact
> the resolution service (the details can be protocol-specific).
> If DDDS is insufficient for this, replace it.   But even if
> DDDS has some specific flaws, the core idea of distributing
> this database over the network is sound.

A non-DNS distribution mechanism for URNs has never been
specified, much less deployed, and that, as far as I know (and
much to my regret), we haven't had a reference or dispatching
database associated with an element of major protocol
successfully distributed by anything other than the DNS since
(depending on what you count) we stopped distributing host
tables or gave up on X.500.   That (and some other remarks)
concern me because it feels as if you are putting major new
design work and consensus about it the critical path of progress
on the current effort.   

However, that generalization of DDDS (or even an analysis,
redesign, and successor) doesn't change my basic point: I
believe that, if one is going to have a resolution method, or
resolution-method-finder, that is namespace independent and
works in a consistent way for all URN namespaces, then there
either needs to be a single resolver that works for all URNs (an
idea that was abandoned years ago, certainly before DDDS was
specified) or that mechanism has to have access to a
comprehensive database and query process that identifies a
resolution mechanism for each URN.  That hypothesis is true
independent (or not) of how similar the database is to that
anticipated by DDDS and to whether or not the query mechanism
for the database is DDDS.  It is also not dependent of just what
information is in the database and how is is retrieved.

   best,
    john

---

From: Keith Moore <[email-masked]>
Date: Tue, 3 Nov 2015 18:36:14 -0500

On 11/02/2015 05:17 PM, Sean Leonard wrote:
> On Nov 2, 2015, at 9:29 PM, John C Klensin<[email-masked]>  wrote:
>

It's hard enough to read through an email discussion.   Trying to keep 
track of a Wiki discussion, or worse, a discussion that takes place 
partially in a wiki and partially in email, sounds like a task of 
Sisyphus.    I'd be happy to find a better discussion medium than email 
(which actually seems to have become less effective in the last 20 years 
or so) but I don't think Wiki is it.   Also, it seems like the last 
thing that this group needs to be dealing with is coming up to speed on 
new tools.   Can't we try instead to focus on matters of substance?

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 3 Nov 2015 18:56:06 -0500

> is meant to represent an XML namespace. If resolved and dereferenced, it is supposed to always return an XML schema (.xsd, application/xml or text/xml), namely the XML schemas that are registered w…
Two questions:

1.  In the case of a URN that named an XML namespace, would returning 
the XML schema be equivalent to accessing the content of that URN, or 
would that need to be a distinct operation?   If not, why not?

2. Say there's an XML namespace that's named by URN that's not an xmlns 
URN.   Should the operation to retrieve the XML schema associated with 
that namespace be different than for a namespace named by an xmlns 
URN?   If so, why?

> Most resolutions, however, are not specific to or defined by the namespace. For <urn:isbn:9999-9999> or <urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>, they could be resolved in lots of ways (acce…

yes.

> But what’s good for one set of identifiers may not be good for another set of identifiers.

My suspicion is that most, but not all, of the resolution services and 
parameters that people want to associate with particular namespaces are 
not in fact inherently specific to those namespaces.   So while it's 
probably necessary to be able to support namespace-specific services and 
resolution parameters, it would be unfortunate if every namespace 
developed its own completely different set of services and parameters.

> And my argument is that even though you could identify an XML namespace with urn:xmlns:foobar2015 and then resolve it into something utterly tangential to the original purpose (e.g., a picture of cats), there really is no functional value in doing so.

I'm not sure how that argument applies to this discussion, but I agree 
with the statement.

>    ELSE <implementation-defined-resolver>(NID, NSS, r-component, q-component)

As I stated elsewhere, I don't think it's appropriate to pass 
q-component to resolution services, since q-component is intended to be 
mapped to "queries" passed in resource URLs, or similar uses when a URL 
isn't involved.   q-component isn't for the resolution service, it's for 
the resource itself.

>   => GETS BACK text/uri-list

I think resolution services should not inherently constrain the 
content-type of the result document.   There will be a need for 
resolution services to support a variety of existing and future formats 
for location information and metadata.

(though it's fine with me if a simple uri-list is one of the kinds of 
content that a resolution service could return)

> If URI has f-component in text/uri-list, the final URI (with fragment) is undefined.

I doubt that a fragment in a URI returned from a resolution service 
should override an f-component specified in the original URN.
In general, I think it's a Very Bad Idea to have the resolution service 
try to mediate access between the user/client and the resource - partly 
because it doesn't scale well, partly because it essentially makes the 
resolution service behave as a central point of control for access to a 
large set of resources.    The resolution service is supposed to 
facilitate access, not act as a central gatekeeper or DRM enforcer.

> As I have stated before, I have proposed eliminating q-component, making everything r-component.

This would be absolutely unacceptable, as it would either make URNs 
useless for referring to resources that accept queries, or it would put 
the resolution service in the position of being a central gatekeeper.

>   In the algorithm above all functions take (r-component, q-component) together, and return URIs that have query components. That is the logical premise on why separating r-component and q-component isn’t necessary.

It's absolutely necessary.  Because it's none of the resolution 
service's business what queries the user is making, and it's certainly 
not within the resolution service's purview to alter or filter such queries.

Keith

---

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

> of his comments as wanting to prohibit resolutions that are

I don't want to absolutely prohibit them, as I think they will be 
necessary in corner cases, or to let namespaces and resolution services 
experiment with new r-component parameters and types of requests.   But 
I do want to discourage namespace-specific requests and r-component 
parameters, or at least encourage development of standard resolution 
protocols and standard resolution requests and results that are 
applicable across the vast majority of cases. The last thing we need is 
for every namespace to go off and do its own thing.

Keith

---

From: Sean Leonard <[email-masked]>
Date: Wed, 4 Nov 2015 09:48:05 +0900

Hello:

(Trying to pay attention to another WG meeting… :) )

On Nov 3, 2015, at 11:29 AM, John C Klensin <[email-masked]> wrote:

>> […]

To be clear: I was referring to the Internet media type “text/uri-list”, namely, the media type defined in RFC 2483, but not necessarily with the rest of the text of that RFC.

A text/uri-list is just a CRLF-delimited list of URIs, with optional # comment lines.

So, when I said “text/uri-list”, I meant that the algorithm returns a list of 0 or more ordered URIs. The URIs are in order so that implies that first URIs are more preferable than later URIs (much like DNS SRV records, and weights).

A URI can represent (unfortunately) … anything. A significant class of URIs will resolve to content that has an Internet media type, e.g., http: URIs, data: URIs, mid: and cid: URIs, etc.; others (like ftp:) have an implicit media type but the URI scheme doesn’t really say how to map them (hence you can assume that .html is text/html but that is not an Internet standard, just a de-facto one); and still others have no media type. I suppose you could have a urn:service: URN that turns into a tel: or mailto: URI, neither of which represent content with media types, but both more-or-less do the thing that you want them to (i.e., contact the service).

Further to this point, Keith said:

On Nov 4, 2015, at 8:56 AM, Keith Moore <[email-masked]> wrote:

> I think resolution services should not inherently constrain the content-type of the result document.   There will be a need for resolution services to support a variety of existing and future formats for location information and metadata.
> 
> (though it's fine with me if a simple uri-list is one of the kinds of content that a resolution service could return)

In discussing how resolution works, it’s very helpful to have some concrete result. If we talk about the algorithm in very hand-wavy high-level terms, we don’t have anything implementable. Saying that the algorithm returns a list of URIs, is an implementable algorithm.

Yes it kicks the can down to another level of indirection, since URIs can be pretty much anything. But it’s computable and I would say that’s what we need to get this URNBIS work done.

An uri-list (obviously) does not constrain the content-type of the final things. Furthermore, if you want to have a URI that only represents location information and metadata, you can do that. For example, the geo: URI scheme was recently standardized, and that will give you location info quite nicely.

Above, I said that uri-list is a list of URIs in priority order. An alternative interpretation is that the uri-list is a SET of URIs (possibly in priority order) that are equally valid. For example, suppose that you want to get purchasing information about a book, urn:isbn:999… etc. The returned uri-list can be https://www.amazon.com/dp/…, http://www.worldcat.org/…, a list of geo: URIs for nearby stores and libraries that carry the book, callto: for a Skype handle to the publisher, and tel: for your local libraries that carry the book. None of these URIs are “more important” than the other; they are just different ways of getting access to information related to the identified thing.

Sean

---

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

> probably stop adding long notes to the conversation until you

I do not.  As far as I can tell, he and I are nearly diametrically opposed.

In particular, I emphatically do not agree that a general-purpose URN 
resolution system is infeasible.   I also regard any change to URNs that 
breaks the ability to have a general-purpose resolution system as a 
fundamental change to URNs that is outside of the scope of this working 
group.   URNs were specifically designed to facilitate not only 
resolution but general resolution mechanisms, and this group is not 
chartered to break that functionality.

However, in case it helps:

  * By saying the above things I do not mean that every URN has to be
    resolvable.   I agree that that is not achievable given the broad
    overall scope of URNs.    This was also generally understood by
    people discussing URNs as early as 1994.
  * By saying these things I do not mean that every namespace has to
    support a resolution service, only that it be possible for every
    namespace to do so if it makes sense for the resources named by that
    namespace.

  * By saying these things I do not mean that if a namespace supports a
    resolution service, the namespace must be able to return information
    for every URN coined by that namespace.

  * By saying these things I do not intend to prohibit all
    namespace-specific resolution operations or interpretation of
    r-components.

> comprehensive listing and responded on that basis.

A lot of misunderstandings in all directions seem to result from the 
need to compromise between being brief and being precise.

>   That sort of

Okay, just so you know, statements of the form "X for URNs has never 
existed" (especially if the implication is "and it never will") aren't 
very relevant to me, because URNs are in their infancy. They're like 
similar statements made a few years ago of the form "X for IPv6 has 
never existed".

But I am not intending to put design of a resolution service on this 
group's charter - I realize that's not going to happen.  I only want the 
group to understand that it shouldn't make decisions that thwart 
general-purpose resolution.

> either needs to be a single resolver that works for all URNs
Why do you believe that?   (or perhaps I should ask, "What do you mean 
when you say things like that?")

Do we need to have a single SMTP server that accepts all incoming 
mail?   A single web server that handles all web content?   The whole 
history of IETF has been one of defining specifications that allow 
multiple implementors to produce implementations that behave reasonably 
consistently from one to another.   Why is defining a standard protocol, 
standard requests, and standard result formats, not a valid approach to 
general-purpose URN resolution?

>   or that mechanism has to have access to a
> resolution mechanism for each URN.
Given that providing resolution for every single URN was never a goal, 
or at least, that that goal was abandoned before the URN WG was ever 
chartered, why is that suddenly a requirement now?   Why do you consider 
that a requirement when (as far as I can tell) everybody else involved 
in URN work abandoned it by 1995?

Even the language in RFC 1737 (published in December 1994) reflects that 
understanding.  for example:

    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/.

(section 2, last bullet)   It doesn't say that the mechanism must exist, 
it says it must be feasible.

    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.

(section 4, penultimate bullet)   It doesn't say "required", it says 
"strongly recommended".

(note: I am not saying that the RFC 1737 text is perfect, just that it 
attempted to reflect the general understanding as of late 1994.)

Keith

---

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

On 11/03/2015 07:48 PM, Sean Leonard wrote:
> Further to this point, Keith said: On Nov 4, 2015, at 8:56 AM, Keith 
> Moore <[email-masked]> wrote:

I understand the discussion dilemma, and often face that myself. Too 
much precision and you lose the reader,  too little and the reader can 
get misleading impressions - especially in a discussion like this one.

I don't think that text/uri-list is a good choice if it's the only 
output format that can be returned, for several reasons.   Perhaps the 
most obvious is that resolution services will be expected to do more 
than provide a list of URLs - they will also be expected to provide 
metadata.   There are several existing formats for various kinds of 
metadata, and it would make good sense if resolution services could 
return them.   Also, even if the service requested is a list of URLs, 
the resolution service is not in a good position to determine ordering 
for the client.   Finally I would suggest that if there's going to be a 
designated format for a list of URLs, it should allow each URL to be 
tagged with zero or more attributes to help the client decide which 
order to consult them in.   (To cite one example from previous 
experience:  Having the resolution service act as a DNS cache for the 
URL servers' IP addresses can result in a tremendous improvement in 
access times.)

But I agree that having a standard way to request a list of URLs of the 
resource, and a standard response format, would be appropriate. I also 
agree that the standard should be simple.  (but it should also be 
extensible)

My suggestion would be

content-type: application/json.uri-list

where the result consists of a single JSON list, each element of the 
list is a JSON object, and each such object has the required the tag 
"uri" and may have other optional tags (defined in an IANA registry, but 
one such tag would be "addresses", and each address would be a tuple 
consisting of an IPv4 or IPv6 address (as a string) and a 
cache-expiration date-time.

Keith

---

From: Sean Leonard <[email-masked]>
Date: Thu, 5 Nov 2015 12:43:08 +0900

On Nov 3, 2015, at 10:42 AM, John C Klensin <[email-masked]> wrote:

> tracker" I wouldn't have objected significantly.

Issue tracker could work.

Anyway well now that we’ve generated so much e-mail traffic, may as well finish this out here, until we completely peter out or start getting elliptical about arguments twice or three times in a row…

Sean

---

From: Andrew Newton <[email-masked]>
Date: Thu, 5 Nov 2015 13:01:06 +0900

> Anyway well now that we’ve generated so much e-mail traffic, may as well finish this out here, until we completely peter out or start getting elliptical about arguments twice or three times in a ro…

I've been thinking about this issue. And just because the wiki idea
has not found favor does not mean there is no problem. Discussions on
this list can be extremely hard to follow.

It's funny that you mention an issue tracker. I use a GitHub issue
tracker for one of my drafts, and it works great. But we tried that
here without success.

Perhaps we need a lot more mailing list discipline. I've seen TZDIST
treat their list like an issue tracker. Maybe we should do the same.

-andy

---

From: Keith Moore <[email-masked]>
Date: Wed, 4 Nov 2015 23:40:56 -0500

> Issue tracker could work.
An issue tracker can work well when the issues are entirely independent, 
and a decision on one issue isn't likely to have significant ripple 
effects.   I'm not sure that's the case for the current state of 
discussion.   When there are significant dependencies between issues, 
you can get rough consensus on a lot of separate issues that, taken 
together, preclude a solution.

Keith

---

From: Sean Leonard <[email-masked]>
Date: Thu, 5 Nov 2015 13:49:58 +0900

On Nov 4, 2015, at 8:56 AM, Keith Moore <[email-masked]> wrote:

>>>> [...]
> 1.  In the case of a URN that named an XML namespace, would returning the XML schema be equivalent to accessing the content of that URN, or would that need to be a distinct operation?   If not, why not?
> 
> 2. Say there's an XML namespace that's named by URN that's not an xmlns URN.   Should the operation to retrieve the XML schema associated with that namespace be different than for a namespace named by an xmlns URN?   If so, why?
> 
> My suspicion is that most, but not all, of the resolution services and parameters that people want to associate with particular namespaces are not in fact inherently specific to those namespaces.   So while it's probably necessary to be able to support namespace-specific services and resolution parameters, it would be unfortunate if every namespace developed its own completely different set of services and parameters.

Keith I see your point, and I gather that the overall gist is that there should be a resolution operation, “get XML namespace schema”, that applies with equal semantics across all URNs. The difference is that urn:xmlns guarantees that such content is available; other namespaces (e.g., urn:oid, urn:uuid) do not make such guarantees but are sufficiently broad or abstract that such schemas can be associated with them; and still other sub-namespaces (urn:ietf:params) are designed to identify XML namespaces but not .

So your point is that a common verb or operation token should apply with equal force across all URNs, rather than defining a “getxmlschema” verb that works in one way with urn:xmlns, but behaves completely differently for another NID. Is that correct?

Another example: urn:isbn identifies books and published works, but some urn:nato identifiers could equally be about books and published works (namely those created by NATO). And perhaps one day the ISBN organization (International ISBN Agency) could totally change its purpose and designate urn:isbn:foobar:… to identify something totally different. So your point is that the verb “return library locations” should apply with equal force across this whole range of URNs. Is that correct?

> I'm not sure how that argument applies to this discussion, but I agree with the statement.

My point is that if you have <foo xmlns:bar=“urn:xmlns:foobar2015”>, and the XML implementation wants to get the schema, the *default* retrieval/resolution action is to return the XSD/XML schema, since “?getxmlschema” is not appended.

I suppose that there is an implicit context in this case, namely that XML processors will dereference URIs with the contextual purpose of filtering through the results for the kinds of things it wants. For example if the URI is HTTP, then the XML processor should set the Accept: header so that application/xml resources are preferably returned. So too with URN resolution: the resolver is queried with some contextual information that says that particular things are being sought (in this case, ?getxmlschema), and that is regardless of what urn: NID is in place.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Thu, 5 Nov 2015 14:21:44 +0900

On Nov 4, 2015, at 10:21 AM, Keith Moore <[email-masked]> wrote:

>> [SNIP]
> I understand the discussion dilemma, and often face that myself. Too much precision and you lose the reader,  too little and the reader can get misleading impressions - especially in a discussion like this one.
> 
> I don't think that text/uri-list is a good choice if it's the only output format that can be returned, for several reasons.   Perhaps the most obvious is that resolution services will be expected to do more than provide a list of URLs - they will also be expected to provide metadata.   There are several existing formats for various kinds of metadata, and it would make good sense if resolution services could return them.   Also, even if the service requested is a list of URLs, the resolution service is not in a good position to determine ordering for the client.   Finally I would suggest that if there's going to be a designated format for a list of URLs, it should allow each URL to be tagged with zero or more attributes to help the client decide which order to consult them in.   (To cite one example from previous experience:  Having the resolution service act as a DNS cache for the URL servers' IP addresses can result in a tremendous improvement in access times.)
> 
> But I agree that having a standard way to request a list of URLs of the resource, and a standard response format, would be appropriate. I also agree that the standard should be simple.  (but it should also be extensible)
> 
> My suggestion would be [JSON list]

I am all in favor of adding optional attributes to URIs (URLs) for metadata as you describe. I actually have been working on a very similar technology for certspec (draft-seantek-certspec), which is a uniform way to identify PKIX certificates and convey associated attributes, which may be preferences, friendly names, trust information, and so on. This used to be urn:cert but I am taking a different approach where the string is not a URI at all. It is of the form:

certid [“|” certattrs] [“#” certfrag]

Namely | is the separator character between the identifier for the certificate, and optional tagged attributes. This is different from the fragment for straightforward reasons.

Similarly, I propose “text/uri-list2”, which is a CRLF-delimited list of URIs, where the URI has optional tagged attributes after the | character:

  http://www.amazon.com/dp/abcde|attribute1="buy",ip="33.33.33.222" 
  data:text/html,base64;MIICS…|attribute1="info"

etc. (In this example, the attributes are formatted as JSON. The outermost data element is a JSON object without the { } characters, CRLF is prohibited since that’s the delimiter between lines, and attribute names do not need to be quoted.)

The reason for this instead of straight JSON is that it is shorter, and we don’t commit ourselves to JSON specifically as the nature and format of attributes is probably way out-of-scope for the URNBIS draft. Also as a bike shedding matter, I prefer CBOR to JSON. :)

But as an analytical framework, hopefully we can reach consensus on the principle that a resolver returns a list (ordered) or set (unordered) of resources--which are URIs or at least representable as URIs--along with optional attributes.

Sean

---

From: Julian Reschke <[email-masked]>
Date: Thu, 5 Nov 2015 09:00:47 +0100

> cache-expiration date-time.

Which reminds me of <http://greenbytes.de/tech/webdav/rfc5988.html>; in 
particular have a look at the way link relations are defined (and they 
have a IANA registry).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 5 Nov 2015 09:06:25 +0100

Best regards, Julian

---

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

> But as an analytical framework, hopefully we can reach consensus on the principle that a resolver returns a list (ordered) or set (unordered) of resources--which are URIs or at least representable…

Agree that that's one possible result.  But if the request isn't for 
URLs but instead for a particular kind of metadata, the resolution 
service should be able to return the requested kind of metadata.

The service should also potentially be able to return information about 
URIs related to (but not necessarily the same as) the resource named by 
the requested URI.   (e.g. the URN I have is for version 2, is there a 
later version available?)

And finally the service should be able to return a list of the kinds of 
information which it possesses about the URI.

Keith

---

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

> Keith I see your point, and I gather that the overall gist is that there should be a resolution operation, “get XML namespace schema”, that applies with equal semantics across all URNs.

Well, that's not really what I was thinking.   I suppose it depends on 
the defined relationship between the URI that names an XML namespace and 
the XML schema of the namespace.   If the defined relationship is such 
that the XML schema of a namespace is the /content/ of that URI, then 
there's no need for there to be a special purpose resolution operation 
"get XML namespace schema", the ordinary "get URLs associated with this 
URI" is sufficient because the schema could then be obtained from one of 
those URLs.   I believe that the fewer resolution operations that only 
apply to a few URIs, the better.   But if that's not the defined 
relationship between the URI and the schema, you probably do need a 
special operation.

That said, I believe that resolution services will need to potentially 
support a very wide range of metadata types that are associated with any 
particular resource, and most of these will be opaque to the resolution 
service protocol engine itself.   So for instance, if the client asks 
the resolution service for metadata of arbitrary type FOO, the service 
will simply look to see if it has a file of metadata of type FOO 
associated with that URI.   If it does, it returns that metadata; if 
not, it says "sorry, I can't do that".   (There might be also the 
capability to translate between a few kinds of known metadata to 
others.   So if the client asks for Simple Dublin Core XML, and the 
service doesn't have that, it might however have the equivalent 
information in some other format and be willing to translate.)

So it might be that the client could just say: I want metadata about 
this URI, and the particular form of metadata that I want is the XML 
schema of the namespace that this URI represents.   To me that sounds 
like stretching the definition of "metadata" a bit.   But the protocols 
would support it, and it would avoid having to define an entirely new 
operation.

> The difference is that urn:xmlns guarantees that such content is available; other namespaces (e.g., urn:oid, urn:uuid) do not make such guarantees but are sufficiently broad or abstract that such schemas can be associated with them; and still other sub-namespaces (urn:ietf:params) are designed to identify XML namespaces but not .

Yes.   Though if I recall correctly the XML namespace specification 
doesn't even constrain the URI to that degree - any URI that uniquely 
names the namespace would do.

(In general I have the impression that people are placing far too much 
emphasis on what they think a particular URN namespace "means".  I 
believe the purpose of URN namespaces is simply to permit federated 
assignment of URNs while still preserving uniqueness and persistence 
properties of URNs,  and people and (especially) software shouldn't be 
inferring resource types by looking at the namespace.  So for instance 
no XML processor should be looking at the URN namespace and saying 
"sorry, that URN namespace is not sufficiently broad or abstract to be 
used to name an XML schema" - it should instead try to obtain the schema 
itself via the normal means.   If that operation fails it can say 
"sorry, I couldn't obtain the schema".)

> So your point is that a common verb or operation token should apply with equal force across all URNs, rather than defining a “getxmlschema” verb that works in one way with urn:xmlns, but behaves co…

I'm not sure what "equal force" means.   But I'm fairly confident that 
if we can define a small number of common resolution operations (things 
like "get URLs of locations of this resource and please return them in 
format X, or Y, or Z" and "get metadata of type FOO associated with this 
resource and return it in either format A or format B")  that are 
potentially applicable to most URNs, we'll get more clients that are 
capable of doing things with URNs, than if we require a separate, 
specific operation like "getxmlschema" to be defined and implemented and 
deployed in resolution services for every different kind of request that 
someone or some client might need to make.

> Another example: urn:isbn identifies books and published works, but some urn:nato identifiers could equally be about books and published works (namely those created by NATO). And perhaps one day th…

Something like that.  If a "return library locations" operation seems 
widely applicable rather than inherently specific to ISBNs (and it does 
to me) then it makes more sense to standardize a "return library 
locations" operation for potential use by any URN than to make that 
operation specific to a namespace or resolution service provider.   Or 
if "return library locations" can be accomplished by 
get_metadata(type=xml-library-locations), where xml-library-locations is 
an identifier for some well-defined schema, that might be better still - 
because a resolution service already supporting "get_metadata" could 
support it without needing a software update.)
> I suppose that there is an implicit context in this case, namely that XML processors will dereference URIs with the contextual purpose of filtering through the results for the kinds of things it wa…
That sounds right.

Keith

---

From: Andrew Newton <[email-masked]>
Date: Fri, 6 Nov 2015 04:55:02 +0900

On Thu, Nov 5, 2015 at 10:08 PM, Keith Moore <[email-masked]> wrote:
> I'm not sure what "equal force" means.   But I'm fairly confident that if we
> can define a small number of common resolution operations (things like "get
> URLs of locations of this resource and please return them in format X, or Y,
> or Z" and "get metadata of type FOO associated with this resource and return
> it in either format A or format B")  that are potentially applicable to most
> URNs, we'll get more clients that are capable of doing things with URNs,
> than if we require a separate, specific operation like "getxmlschema" to be
> defined and implemented and deployed in resolution services for every
> different kind of request that someone or some client might need to make.

What specific changes are you asking for in 2141bis? As the IETF
saying goes, "send text". Otherwise I think this line of thought
should end here.

-andy

---

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

> saying goes, "send text". Otherwise I think this line of thought

So when people make handwaving arguments to the effect that there's no 
need to make sure that URNs can be resolved in a general fashion, those 
unsupportable arguments are apparently just fine.   But when people try 
to discuss specifics of how it could be done, as a proof of concept, 
those arguments are out of order?

I'm really getting tired of all of the efforts to cripple URNs.

Keith

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 6 Nov 2015 08:30:21 +0000

Hello, 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Keith Moore
> Sent: 6. marraskuuta 2015 6:06
> To: [email-masked]
> Subject: Re: [urn] -14
> 
> >> can define a small number of common resolution operations (things
> >> like "get URLs of locations of this resource and please return them
> >> in format X, or Y, or Z" and "get metadata of type FOO associated
> >> with this resource and return it in either format A or format B")
> >> that are potentially applicable to most URNs, we'll get more clients
> >> that are capable of doing things with URNs, than if we require a
> >> separate, specific operation like "getxmlschema" to be defined and
> >> implemented and deployed in resolution services for every different kind of
> request that someone or some client might need to make.

Defining URN resolution services and r-component syntax related to them will be done once we have agreed that r-component can be used. I have volunteered to participate in this work to make sure that services and service parameters specified will match the real requirements of libraries, archives and museums. 

An obvious starting point is to specify r-component syntax for services specified in RFC 2483. Some of these services must be parametrized; for instance, if metadata about resource is wanted, it is usually also necessary to specify the format (Dublin Core, MARC 21, ONIX and so on). It may also be necessary to specify the type of metadata required (rights metadata, technical metadata, descriptive metadata, and so on). 

There are services which are already possible with the current generation of digital asset management systems, but which are not included in RFC 2483. And once new services emerge, it must be possible to add them. So the first priority is to create mechanism with which the list of services and their syntax specifications will be maintained. 

> So when people make handwaving arguments to the effect that there's no need
> to make sure that URNs can be resolved in a general fashion, those
> to discuss specifics of how it could be done, as a proof of concept, those
> arguments are out of order?
> 

As far as I am concerned, the details of r-component syntax should be dealt with after 2141bis has been completed. Adding the task of r-component specification to the agenda might delay us further by several months in the worst case. And there is definitely no urgent need to specify the details of r-component now. 

As regards q-component, we do not need to do anything, since q-components will be something that target systems will be able to deal with, based on (hopefully) some standards. So SRU protocol can be used to retrieve metadata from target systems, and other protocols for retrieving the documents themselves. 2141bis does not need to be aware of these protocols; we only need to specify q-component as a place within which to put the string that does the trick required. 

Juha 
> 
> Keith
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Nov 2015 04:54:48 -0500

Keith,

Independent of the virtues of your substantive positions, I
think the above is a severe mischaracterization.  As far as I
can tell, no one who has been active on this list in recent
months is trying to cripple URNs.  What we are trying to do is
to find a way to write a URN standard that is (i) consistent
with known existing uses and plausible future ones that are not
completely off the wall and (ii) that can be finished somewhat
in advance of the heat death of the universe and preferably
within a small number of months.  To at least some of us, what
we are looking for more nearly resembles "expand the range and
functionality to at least match reality" than it does "cripple"

At least for me, the means getting very pragmatic rather than,
e.g., theorizing about what we might do if it had infinite time
and a clean slate. I see the alternative as ending up with no
IETF standard to which most actors don't bother to pay attention
and either no other standard or a collection of different ones,
from different bodies that have different interests and
priorities, and that are not consistent or compatible.  I don't
think we have unlimited time; I'm surprised we haven't run out
of time already.

Again for me, that means approaching every new (or repeated)
idea and proposal with questions like:

(i) Is this really critical path?  If it is not, can we put it
aside (even if only temporarily) and focus on things we actually
need to do to get the present set of documents completed and
published?

(ii) It is likely that this particular idea can be documented
and consensus reached in a reasonable amount of it (where
"reasonable" includes recognizing that we are already years
overdue on the core work)?  If not, can we postpone it or set it
aside until the base documents, with no normative forward
references or statements that would discourage use without the
new features, can be completed?

(iii) Closely related to be above, is the idea sufficiently
clear and specific to be actionable or is it merely a statement
of vague principles?  If the latter, is it safe to ignore it
and, if not, why not.

You may not agree with that way of looking at things, but it is
motivated by a focus on getting finished, not on an effort to
"cripple".

There is another important aspect of URNs that I think we should
keep in mind.   While there are certainly important exceptions,
one of them brought about by the idea that one can embed any URI
in an HTML "aref", in many, perhaps most, application
situations, the application developer is perfectly aware of the
range of URNs (with or without other URI types) that are likely
to be relevant.   For that range, it is entirely reasonable to
assume that the application will have knowledge of whether
resolution is needed and a resolver, resolution-database or
dispatcher, or a set of per-namespace resolvers, readily
available.   

In that situation, a "universal" mechanism is needed only for
the namespaces that are relevant.  Other kinds of namespaces and
their resolution mechanisms are either not relevant or are an
attack vector.  I don't have time to try to explore all of those
details and suspect the WG doesn't either.  But, just as I don't
think the recent discussions can be reasonably characterized as
trying to cripple URNs, I don't think "can't figure out how to
either find an authoritative resolver or authoritatively
determine that one is not needed" is really a showstopper for
the effort to define URNs that are extended enough beyond 2141
to match today's realities.

best,
    john

---

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

On Fri, Nov 6, 2015 at 1:06 PM, Keith Moore <[email-masked]> wrote:
> unsupportable arguments are apparently just fine.   But when people try to
> discuss specifics of how it could be done, as a proof of concept, those

Are you discussing specifics of URNs? I cannot discern that. You have
been discussing protocols that use Dublin Core XML and some thing that
returns URLs in a JSON format that does not yet exist. And you are
doing it all in an email thread about the 2141bis -14 draft version.

So is there something you want specifically added to the draft? If you
do, send text.

-andy

---

From: Keith Moore <[email-masked]>
Date: Mon, 9 Nov 2015 08:15:26 -0500

On 11/06/2015 04:54 AM, John C Klensin wrote:
> within a small number of months.

As far as I can tell, the constant demand to keep the scope of the 
discussion so narrow is actually making the effort take far longer than 
it needs to take.   Take r-components, for example.  Having a clean 
separation between parameters to the resolution service and parameters 
sent to the resource appears to make good sense.   But in order to get 
the particulars of r-components right or even approximately so, we need 
to work out in more detail how they'd actually be used.

For example: Based on the work I've done so far it appears that the 
entirety of a service request to a resolution service should be 
specified in an r-component.   That seems to make more sense than trying 
to separate client-supplied parameters and parameters supplied in the 
r-component of the URN and having the resolution service resolve the 
conflicts between the two.   It follows that clients need to be able to 
understand at least some facets of r-components and be able to remove or 
alter them under some conditions.   It follows that at least some of the 
facets of r-components need to be standardized and applicable across all 
resolution services, and this begs the question of how to distinguish 
between those facets and facets that are specific to a particular 
namespace or resolution protocol.

Now it might be the case that a different way of interpreting 
r-components would work better.  The point is that there's no way to 
know without describing, and discussing, those things in more concrete 
detail.   And there's no way to have a useful discussion without 
exposing that detail.

As long as we're trying to avoid doing those things, everyone's reaction 
to a proposal is based entirely on speculation and/or fear.   When, due 
to a lack of detail, people constantly overreact to proposals based on 
what they imagine might be the result, it's difficult to ever reach any 
kind of agreement.   And even if people reach apparent consensus, that 
apparent consensus might disguise significant differences in how the 
specifications are interpreted, that will create operational problems 
later on.

> To at least some of us, what

"Reality", in my experience, is highly subjective.   Everyone's idea of 
reality is different.

> and a clean slate.

Nobody said anything about either infinite time or a clean slate. I have 
in fact strongly objected to people's efforts to clean the slate, and 
I'm as painfully aware as anyone that time (both calendar time and real 
time) is precious.   But I've seen a lot of examples of willingness to 
disregard requirements that were long established, clearly stated 
(especially in comparison with much of the current discussion), and 
agreed on by WG consensus, in favor of new requirements that are not 
clearly stated and for which informed consensus is dubious at best.

> I see the alternative as ending up with no
> (i) Is this really critical path?

Yes.

> overdue on the core work)?

Yes, but not if we keep avoiding looking at the situation in sufficient 
detail.   (and let's try to avoid using the sunken cost fallacy as an 
excuse to avoid doing what makes the most sense now.)

> of vague principles?  If the latter, is it safe to ignore it

We absolutely must become more specific in our discussions, because it 
is not safe to ignore the details of how resolution will work.

> the namespaces that are relevant.

Having a universal resolution mechanism does not preclude an application 
from using other mechanisms.   Neither are applications precluded from 
having and exploiting knowledge of specific URN namespaces, because 
there are clearly at least edge cases where it's useful for applications 
to be able to do this.   At the same time, I resist the notion that 
URN-aware applications in general should have to be aware of namespaces 
in order to function, or that it makes sense to let every namespace 
define its own resolution protocols, r-components and whatnot without 
any effort to produce a common framework.  As I've argued on multiple 
occasions, this undermines the purpose of URNs of being long-term stable 
resource names, because without a common framework it's likely that only 
the most popular namespaces will be supported over a long period of time.

So I see the purpose of URN standardization efforts as to work out how 
URNs and URN resolution work in a general fashion.  Specific 
applications can, and will, do what they wish.   It's the general case 
that requires standardization, not what specific applications do.

If a particular namespace wants to say "resolution is meaningless for 
names in this namespace", fine.   We can make that discoverable too.

> Other kinds of namespaces and
I'm not even sure what you mean here.    Again, the lack of specifics 
makes it hard to have a useful discussion, and I'm tired of trying to 
counteract others' vague arguments with my own vague arguments.

Keith