Subject: Re: [urn] Namespace consensus and registrations

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

On 4/16/15 6:28 AM, Keith Moore wrote:
> On 04/15/2015 11:02 PM, Peter Saint-Andre - &yet wrote:
>>> Perhaps the simplest and clearest response that I can offer is that I
>>> don't care what the label is ("Expert Review" vs "IETF Consensus" or
>>> whatever), so much as I care that there be an opportunity for public
>>> review.   If the process specified for "Expert Review" requires that
>>> there be public review, that the opportunity for review is advertised in
>>> IETF and other appropriate fora, and especially if we can somehow
>>> arrange that the "expert(s)" considering the results of that public
>>> review really do understand the subtleties of URNs (admitting that this
>>> is really difficult), I'm okay with that and think it's about the best
>>> that we can do. It's potentially even better than "IETF Consensus"
>>> because while that does require public review, nothing about the process
>>> for choosing Area Directors ensures that IESG will have URN expertise.
>>>
>>> So I'll be very interested to read -11's text on this subject.
>>
>> Even before version -11, 2141bis (and before that 3406) stipulated
>> that discussion was to occur on the [email-masked] list. I would
>> prefer that we deprecate the urn-nid list and have discussion on this
>> list, but in any case, yes, public review is very much part of the
>> process.
>
> Given the apparently small number of active participants on this list,
> I'm not sure that's the best way to ensure wide review among the
> communities who would be most concerned with maintaining URN sanity.   I
> realize that having narrowly-focused but yet mostly-unmoderated mailing
> lists that can occasionally blow up is the IETF Way, but there might be
> some parties who would just like to get something similar to Last Call
> announcements for URN namespaces without having to subject themselves to
> arbitrary amounts of email traffic.  Even within IETF, there seems to be
> a set of people who are interested in and knowledgeable about URNs who
> don't participate on this list.
>
> Maybe there could be two lists, urn-announce and urn-discuss? (perhaps
> this list could serve the latter role)   urn-announce traffic could be
> forwarded to urn-discuss, but not vice versa?   Any announcements of
> proposed URN changes could be sent to urn-announce but would request
> that responses be sent directly to the expert(s) evaluating the proposal
> rather than as replies to the urn-announce list.

In the interest of reducing complexity, I would prefer to have one list 
and to have it be this list ([email-masked]).

> (Also, the comment period should last long enough that any organization
> that cares would have time to discuss things within its membership and
> form its own opinion, which probably means a comment period should last
> considerably longer than a month.)

Right now, draft-ietf-urnbis-rfc2141bis-urn has no time limit on reviews 
(RFC 3406 said it was 2 weeks). It might be best to say that the expert 
reviewers need to reply within 2 weeks, not that all discussion needs to 
be completed in 2 weeks (which is unrealistic anyway).

Peter

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 May 2015 08:27:14 -0400

--On Tuesday, May 26, 2015 16:19 -0600 Peter Saint-Andre - &yet
<[email-masked]> wrote:

>> (Also, the comment period should last long enough that any
>> organization that cares would have time to discuss things
>> within its membership and form its own opinion, which
>> probably means a comment period should last considerably
>> longer than a month.)
> 
> Right now, draft-ietf-urnbis-rfc2141bis-urn has no time limit
> on reviews (RFC 3406 said it was 2 weeks). It might be best to
> say that the expert reviewers need to reply within 2 weeks,
> not that all discussion needs to be completed in 2 weeks
> (which is unrealistic anyway).

How would you feel about a sentence indicating that the reply
might recommend other actions -- discussion on specific other
mailing lists, pursuing standardization, etc. -- as well as
commenting on the proposed registration itself.

On a related note, I think it is entirely reasonable to include
space in the template for people to describe how their namespace
uses any or all of p-/q-/r-/f-components without getting
involved with elaborate standardization attempts or registration
models for the syntax and contents of those fields.

    john

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 May 2015 08:35:10 -0400

> models for the syntax and contents of those fields.

Strongly disagree with this.

- I thought we had done away with p-components and just decided to 
permit '/' in NSS.
- q-components are interpreted by the resource, not by the namespace.  
It's very important to make this clear, otherwise there will be tussles 
over their use.
- f-components are interpreted in light of the resource content, not by 
the namespace.  It's very important to make this clear, otherwise there 
will be tussles over their use.
- r-components could potentially be namespace-specific, but different 
namespaces shouldn't interpret the same r-components in different ways, 
any more than different email providers or user agents interpret 
different email header fields in different ways.

Keith

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 May 2015 13:59:49 -0400

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

>> On a related note, I think it is entirely reasonable to
>> include space in the template for people to describe how
>> their namespace uses any or all of p-/q-/r-/f-components
>> without getting involved with elaborate standardization
>> attempts or registration models for the syntax and contents
>> of those fields.
> 
> - I thought we had done away with p-components and just
> decided to permit '/' in NSS.

Keith,

This is another example of the reasons why I am finding all of
the theorizing and repetitive threads involving very few people
to be problematic.

What I had understood from trying to follow the various threads
is that we were getting close to agreement on a particular way
to talk about "/".  I hadn't make the leap from there to "done
away with p-components".  More broadly, I don't get from "one or
two people repeated themselves several times" to "we agreed" (or
"we had done away with").  There have been no comments from
anything resembling a diverse group of WG participants and the
number of consensus calls or other comments from the co-chairs
on this subject has been, well, very small.

> - q-components are interpreted by the resource, not by the
> namespace.  It's very important to make this clear, otherwise
> there will be tussles over their use.

I don't see any conflict between "interpreted by the resource"
and a statement of intent about the namespace.  After all,
namespaces are supposed to be managed and relatively
homogeneous.  One of the important changes in 2141bis is that we
are reducing the external documentation requirements in favor of
requiring (in a few cases) and allowing (in most) more
information in the registration templates. 

As an example, if we created a namespace of cattle, I'd expect
the registration to say, somehow, "this is about cattle".  It
might even distinguish between dairy-type cattle and beef-type
cattle.  The NSS might contain names for subspecies of cows.  If
it contained a designation of a farm or ranch and the name of a
specific cow, it would be getting perilously close to a locator
with persistence that might not last beyond the cow's lifetime.
If someone gets past the management process and slips a duck in
there, I can imagine its causing all sorts of problems and would
hope that one of them would not be an attempt to prove that
ducks are really cows by virtue of their being a duck in the cow
namespace.    There is absolutely nothing we can do in the URN
definition to prevent that duck.   We can, however, allow "this
is about cattle" statements in the namespace registration and
even allow "don't bother asking for things with feathers, you
will get misleading results" statements in the query-explanation
part of the registration.

An explanation in the registration about how the namespace
expects queries to be used seems helpful in that regard.
Without it, the odds of meaningless queries rises and, because
of the way URIs are often implemented, meaningless queries tend
to produce meaningless or very confusing responses to users.

The other issue raised by your comment above is that I have no
actual idea what "interpreted by the resource" means.  I have a
better idea when you say "in light of the resource content, not
by the namespace" as you do for f-components, but only a little.
I am more sure what the latter means, and what the "interpreter"
might do, if the result of interpreting/ resolving a URN is a
URL, particularly and HTTP or HTTPS URL, but, coming back to
that URN for a cattle namespace, I'm fairly confident that an
r-component that distinguished between a request for "picture of
object/resource" and one for "example of object/resource" would
be well-defined but I wouldn't relish the notion of having the
cow-object do the resolution.  I also think that a q-component
(or even an f-component) specifying the right haunch would be
well-defined for either the picture or the sample but that it
might not produce good results if that duck were included in the
namespace.

All of that suggests two things to me:

(1) Discouraging people from offering definition and guidance in
registration requests is probably not a good idea, no matter
what ideas we might have about purity of the URN concept.

(2) While I'm comfortable saying general things and offering
general guidance, the distinctions among r-, q-, and
f-components (and maybe p-components if there is such a thing),
what they "mean", and where and by what they are resolved get
very fuzzy very quickly when abstracted to "names", potentially
of classes of things that cannot be rigidly defined with
enforceable boundaries, rather than web-specific locators and
machine readable objects.

> - f-components are interpreted in light of the resource
> content, not by the namespace.  It's very important to make
> this clear, otherwise there will be tussles over their use.

See above.

> - r-components could potentially be namespace-specific, but
> different namespaces shouldn't interpret the same r-components
> in different ways, any more than different email providers or
> user agents interpret different email header fields in
> different ways.

I think that is an attractive idea in principle but, absent a
grand unified theory of everything, it is unattainable as soon
as we accept the fact that different URN namespaces, and the
resources to which they may refer, can be _really_ different.
I believe that even the discussions of the last month fairly
clearly illustrate that either trying to standardize the
internal syntax of r-components (such as to differentiate
between something organized around name-value pairs and
something organized around something SQL-ish) or to create a
registry of assertions or actions would be a WG killer from
which neither we nor URNs would ever recover.

best,
     john

---

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

> the theorizing and repetitive threads involving very few people

I share your frustration with the small number of participants. And yet, 
it's hard to escape the impression that it's okay for some people to do 
theorizing and repeat themselves, but not for others.

> on this subject has been, well, very small.

In a very small group of participants, some/most of whom pop in only 
occasionally, it's hard to know how to evaluate consensus.   I thought 
we had moved past p-components into simply allowing '/' to appear in an 
NSS, but others may still be thinking in terms of p-components.   That's 
fine - but I think it is better to state assumptions and let others 
challenge them, than to leave them unstated and assume that everyone 
else is thinking the same way.
> homogeneous.

Speaking of theorizing, I'm wondering where that idea came from. I don't 
believe that namespaces are "supposed" to be relatively homogeneous.   I 
might have forgotten but I don't recall seeing that in any of the URN WG 
consensus documents (1737, 2141, etc.) nor do I recall anything 
resembling a consensus on that from URN WG discussion.

(And again, we should be careful about overgeneralizing from early use 
of URNs.   So I don't think existing URN namespaces should be used as an 
argument in favor of dictating policy, unless of course we've identified 
something from early use that's broken and needs to be fixed.)

What I do believe is that it's fairly natural for URN namespaces to be 
aligned with specific user communities, especially communities that 
already have their own namespaces established.    And such communities 
and other pre-existing namespaces have often formed around particular 
kinds of content or media.   So there's an observable tendency for 
existing URN namespaces to be aligned with particular kinds of content 
or media.   But that's not a requirement, and it shouldn't be 
interpreted as one.

Back to q-components.   The first issue I have with documenting them as 
part of URN namespace registration is that this threatens to conflict 
with the notion that when a URN is resolved to a URL, a q-component 
attached to that URN becomes a query attached to that URL.   That's a 
nice, simple way of interpreting q-components that is highly likely to 
be implemented correctly, highly likely to be interoperable between 
different implementations, makes sense across all namespaces, and 
doesn't make resources that accept queries less functional when named by 
URNs.     That's awesome, and I wish we could make everything we do in 
IETF work that well.

But if there's also a namespace-specific interpretation of q-components 
that's specified in that namespace's registration, then there are *two* 
specifications for how to interpret a q-component, and a very high 
probability of conflict between the two.   This is what I want to 
avoid.    I don't want client implementors trying to second-guess 
whether to interpret q-components according to each namespace's 
registration vs. the general rule for handling q-components.   And I 
don't want namespaces to get the idea that they can override 
interpretation of q-components.

Second concern:   Of course, if a namespace wants to decree that it will 
only assign its URNs to resources that implement q-components in one 
particular way, and it wants to document that, it's free to do so.   And 
if that namespace wants to document that information, they should be 
free to do so.   But putting spaces for that in the URN registration 
template is basically encouraging them to nail down their specification 
for q-components.   In addition to the interoperability concerns I 
stated above, I think this is probably shortsighted.   It's basically 
encouraging the namespace to say "we know what q-components are going to 
need to look like for every resource we want to name, for all time, or 
at least until we update our namespace registration".   And I think 
media are changing so quickly these days that it's very hard to 
anticipate what future needs will be.   So I don't think IETF should 
particularly encourage that level of specification in general.   For a 
couple of namespaces it might make sense, but I think those are corner 
cases rather than the general case.

My concerns for f-components are similar.   Again, I thought 
f-components were supposed to map to URL fragments, and fragments are 
(for better or worse) supposed to be independent of the name or service 
used to access the content.    So we don't want to give URN namespaces 
the impression that they can override this in the namespace 
registration.   And again, if a URN namespace elects to refuse to assign 
its URNs to any resources that contain fragment IDs that don't conform 
to its standards for naming fragments, it's free to do so, but I think 
that's probably shortsighted and IETF probably shouldn't encourage it in 
general.   It might make more sense in a couple of corner cases.

As for r-components, I'll address those in a separate message.

Keith

---

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

All,

> theorizing and repeat themselves, but not for others.

I can only speak for myself, but I'm not always in a position to fully understand the consequences of certain engineering decisions and I certainly cannot fully appreciate all the decisions taken 20 years ago. My contributions are more from the pow of a memory organisation having a large base of deployed URNs but also see that the current specifications are extremely limiting and that we need to move forward. Since our job is to ensure that certain classes of resources that we manage (aka "documents") are still available and -- more importantly -- addressable in 500 years (or more). This perhaps boils down to three requirements:
1) persistence of coupling between name and object
2) possibility to resolve a name to an object, its metadata or a tombstone (if the object is not available any more).
3) backward compatibility: we must not break existing URNs

1) and 2) are about registration and resolution. 3) is about syntax, and since we do have some URNs with '/' in them (minted by mistakes several years ago before we had proper quality control in place) I'm actively advocating the '/' be permitted in the NSS. If we decide to call it "p-component" or not is of minor importance...

> else is thinking the same way.

OK, I speak up. It might matter if we have a p-component since there might be namespaces that will not allow '/' for backward compatibility. That is, however, the only use case I can think of. For me it would work to say that we simply allow '/' in the NSS.

> resembling a consensus on that from URN WG discussion.

The namespace NBN is in so far homogeneous in that it deals (mostly) with documents. The homogeneity ends there since the documents can be of almost any existing or future media type, some perhaps accepting q- or f-components, others not.

> something from early use that's broken and needs to be fixed.)

WFM as long as we don't break backward compatibility.

> or media.   But that's not a requirement, and it shouldn't be

I think at least some namespaces are extremely heterogeneous (see above) and my guess is that those have the largest number of deployed URNs...

> As for r-components, I'll address those in a separate message.

Best,

Lars