Subject: Re: [urn] 3986 relationships

From: Andrew Newton <[email-masked]>
Date: Wed, 1 Apr 2015 15:32:53 -0400

On Tue, Mar 31, 2015 at 6:18 PM, Keith Moore <[email-masked]>
wrote:

>  Regarding 3986 in general, I recognize that there's a conundrum here.
> As I understand things, the AD explicitly imposed 3986 syntax on this
> group.   So I undertand that the group has a hard time recommending a
> different approach.   Also, much of the group has long believed that 3986
> is adequate, and maybe there's already some use of that syntax in deployed
> URNs, so there's a lot of inertia behind that syntax.
>
>
There was a proposal before the working group to complete separate URNs
from 3986, and it was the working group decision to adhere to 3986 syntax
but to let go of 3986 semantics. Many pointed out that in today's world,
URNs do appear in places where URIs are expected (XML namespace
specifications are a great example).

> So, regardless of what I personally believe, I'm not really trying to
> persuade you or the group that 3986 should be abandoned.    I do, however,
> think that, having decided to use that syntax (or having had that syntax
> imposed on it), the group has to solve the problems that result from that
> decision before it can expect its document to be approved as a proposed
> standard.
>
> I continue to believe that the decision to use that syntax will result in
> a tremendous amount of harm and confusion, because it's using a syntax that
> people are accustomed to using with http and other URLs, but in very
> different ways - and perhaps even in ways that vary arbitrarily as far as
> users are concerned.   But at least for the time being, that's irrelevant
> unless/until either IESG rejects the document (perhaps realizing that the
> result just creates too many problems) or an AD or IESG action gets
> overturned on appeal.
>
>
How do we quantify that type of harm? Especially against the knowledge that
we will break many things currently in use today if we do not adhere to
3986 syntax?

> So basically I think the immediate task before us is to clean up the
> messes created by RFC 3986 and the decision to allow {f,p,q}-components in
> URNs.
>
> On 03/29/2015 09:46 PM, John C Klensin wrote:
>
> Note that this issue is, I believe, somewhat redundant with one
> discussed in an earlier note.  I've tried to refer to it when
> appropriate; please forgive remaining redundancy.
>
>
> Yes, there is overlap, because these various AD and WG decisions interact
> and have cumulative effects.  It's difficult to talk about these effects
> one at a time without introducing some redundancy, though splitting up the
> topics is probably still a good way to have the discussion.
>
>  --On Thursday, March 26, 2015 11:58 -0400 Keith Moore<[email-masked]> <[email-masked]> wrote:
>
>
>  ...
> 4.  Constraining URNs to RFC 3986 conventions is problematic.
> One reason is that when using URNs to refer to
> network-accessible resources there is a need for more
> functions than those analogous to: references to internal
> structure (presumably f-component), references to external
> structure (presumably p-component), and access to the resource
> as a service (presumably q-component).
>
>  Those presumptions are not clear to me and may not be shared.
> See my earlier discussion about interactions with a presumed URN
> resolver versus pass-through to URL results and then try to
> generalize it to URNs with different kinds of resolution
> mechanisms and targets/results (if you have any trouble at all
> picturing that for the general case, we are in the same boat and
> that is why I didn't expand on that example).
>
>
> A small number of examples illustrate why it is problematic.
>
> 1. A URN from a namespace which uses f-components is associated with,
> and/or resolves to, either an HTML document or a service that produces an
> HTML document when it is accessed.   That HTML document contains relative
> URIs that refer to fragments internal to, and identified within, that HTML
> document.
>
>    - With the f-component used for some other purpose, there is no way to
>    externally refer to those fragments.
>    - Also, any relative URI references within that document will cause
>    the document reader to construct identifiers that look like URNs contining
>    the base URN + the fragment identifier, and those identifiers will likely
>    leak in various ways (in the user interface, browser history, etc.) that at
>    the very least cause user confusion about how URNs are used.
>
>
> (note that there's no assumption here that there's any intermediate URL
> that also refers to the document, though there might be.)
>
> 2. A URN from a namespace which uses p-components is associated with,
> and/or resolves to, either an HTML document or a service that produces an
> HTML document when it is accessed.   That HTML document contains one or
> more relative URIs that contain "paths" that will, in the context of that
> HTML document, be evaluated relative to the URN used to access or obtain
> that document.   Again, those relative URI references will leak in various
> ways that will likely cause confusion.
>
> 3. A URN from a namespace which uses q-components is associated with,
> and/or resolves to, either an HTML document or a service that produces an
> HTML document when it is accessed.   That HTML document contains either one
> or more relative URIs that contain "queries" and/or one or more HTML forms
> which use the GET method.   In order to submit the form, the client reading
> the HTML document will construct a URI from the base URN and the form
> parameters using RFC 3986 "query" syntax.
>
>
In a previous discussion on this list, relative resolution of URNs was
discussed. As it stands today, relative resolution with regards to URNs is
problematic at best. If your assertions are correct, this confusion would
only break something that is already broken.

> 4. A URN is used to identify a service which is accessed using HTTP[S].
> That service accepts query parameters using RFC3986 syntax.    With the
> current 2141bis language, there is no way that a client, user, or document
> author can reliably construct a URI which is a composition of the URN used
> to identify the service and the query parameters.   If that client, user,
> or document author happens to know how that particular namespace's resolver
> works, that person might be able to construct such a URI - but those
> assumptions fail with generic resolvers.
>

I guess we have not discussed the issue of generic URN resolvers (or if we
have, its been done at an abstract level). Maybe this working group should
explicitly discuss if considerations for generic URN resolvers are
relevant. In my message from the other day, I noted that I could not find
any implementations of a generic URN resolver. Given that, do you believe
we have an obligation to continue with requirements for such software?

>
> 5. A URI or other string is constructed by adding one or more f-, p-, or
> q- components to a base URN, following RFC 3986 syntax.   It's not clear
> from 2141bis -10 whether the resulting string is persistent or not, and
> this might vary on a per-namespace basis.
>
>
I agree. We need to discuss this.

> 6. Users who are familiar with HTTP and other URLs will see '#', '/', and
> '?' in URNs and think they know what these mean, think they know how to
> manipulate them.   (There's been a tremendous amount of misunderstanding
> about URNs, even within IETF, which has hampered the actual utility of URNs
> even by those who understand them.)
>

 What types of users are you referencing? End users? Programmers? Protocol
specifiers? This is just my opinion, but I would guess that end users have
no idea what these different components mean or do and they never will. My
experience with URI libraries tells me that programmers will also be in the
dark for sometime to come*. And we know that protocol authors have asked
for these changes.

-andy

* Aside: I know the IETF says it does not do APIs, but a URI/URN reference
API would probably have been a good thing. The state of URI libraries is a
mess, whereas the APIs for sockets are in much better shape and are very
similar from one language to another.

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2015 17:49:45 -0400

On 04/01/2015 03:32 PM, Andrew Newton wrote:
>
>
> On Tue, Mar 31, 2015 at 6:18 PM, Keith Moore 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Regarding 3986 in general, I recognize that there's a conundrum
>     here.   As I understand things, the AD explicitly imposed 3986
>     syntax on this group.   So I undertand that the group has a hard
>     time recommending a different approach.   Also, much of the group
>     has long believed that 3986 is adequate, and maybe there's already
>     some use of that syntax in deployed URNs, so there's a lot of
>     inertia behind that syntax.
>
>
> There was a proposal before the working group to complete separate 
> URNs from 3986, and it was the working group decision to adhere to 
> 3986 syntax but to let go of 3986 semantics. Many pointed out that in 
> today's world, URNs do appear in places where URIs are expected (XML 
> namespace specifications are a great example).

Yes they do.   But IMO, the harm presently done is minimal for the 
following reasons:  (a) With RFC 2141 syntax (no use of '/', '?', or 
'#') there are many fewer ways for the URN to fail than with rfc2141bis 
URNs.  (b) If an existing use of the URN broke things immediately, the 
URN would be replaced with a different kind of URI, so it's reasonable 
to assume that if a particular way of using a URN causes immediate, 
obvious, and consistent breakage, people will learn to not use them in 
that way.   (c) Many of these are cases, like XML namespaces, where all 
that is really required is a unique string that has to be formatted as a 
URI.   The URI is probably not even parsed, the resource is not 
accessed.  The most that is done is that the URI compared for 
equivalence against other URIs.

Also, 3986 syntax was deliberately a superset of 2141 syntax, so code 
written to parse URIs according to 3986 shouldn't fail with RFC 2141 
URNs.  That shouldn't be taken as any indication that use of 
f-components, p-components, and/or q-components with URNs won't break 
things.   If this WG can't even agree on how to interpret those 
components in a consistent fashion, existing code is highly unlikely to 
interpret them reasonably.  To put it another way, URNs that include any 
of these new components won't do anything useful with existing code no 
matter what syntax is used, so from the interoperability standpoint 
there's little benefit in overloading 3986 syntax.

But I also believe that it's possible to define some profile of 3986 
syntax that will permit "traditional" references to fragments and paths 
and use of queries, as well as perhaps some similar facilities that make 
more sense with URNs (if we could manage to define them), as well as the 
ability to communicate requests and parameters to resolvers.   I just 
think that the result is either going to be *really* ugly and confusing 
to users, or significantly less functional than URLs.   So it's not a 
technical problem so much as a usability problem and a question of 
whether something that's so ugly will actually be able to be reliably 
used in practice.

>     So, regardless of what I personally believe, I'm not really trying
>     to persuade you or the group that 3986 should be abandoned.    I
>     do, however, think that, having decided to use that syntax (or
>     having had that syntax imposed on it), the group has to solve the
>     problems that result from that decision before it can expect its
>     document to be approved as a proposed standard.
>
>     I continue to believe that the decision to use that syntax will
>     result in a tremendous amount of harm and confusion, because it's
>     using a syntax that people are accustomed to using with http and
>     other URLs, but in very different ways - and perhaps even in ways
>     that vary arbitrarily as far as users are concerned.   But at
>     least for the time being, that's irrelevant unless/until either
>     IESG rejects the document (perhaps realizing that the result just
>     creates too many problems) or an AD or IESG action gets overturned
>     on appeal.
>
>
> How do we quantify that type of harm? Especially against the knowledge 
> that we will break many things currently in use today if we do not 
> adhere to 3986 syntax?

See above - introduction of new components to URNs is going to break 
things no matter what syntax is used, *especially when those components 
aren't even interpreted consistently from one URN to another*.

But I agree that it's difficult to quantify that type of harm.

>     So basically I think the immediate task before us is to clean up
>     the messes created by RFC 3986 and the decision to allow
>     {f,p,q}-components in URNs.
>
>     Yes, there is overlap, because these various AD and WG decisions
>     interact and have cumulative effects.  It's difficult to talk
>     about these effects one at a time without introducing some
>     redundancy, though splitting up the topics is probably still a
>     good way to have the discussion.
>
>>     --On Thursday, March 26, 2015 11:58 -0400 Keith Moore
>>     <[email-masked]>  <mailto:[email-masked]>  wrote:
>>
>>>     ...
>     1. A URN from a namespace which uses f-components is associated
>     with, and/or resolves to, either an HTML document or a service
>     that produces an HTML document when it is accessed.   That HTML
>     document contains relative URIs that refer to fragments internal
>     to, and identified within, that HTML document.
>
>       * With the f-component used for some other purpose, there is no
>         way to externally refer to those fragments.
>       * Also, any relative URI references within that document will
>         cause the document reader to construct identifiers that look
>         like URNs contining the base URN + the fragment identifier,
>         and those identifiers will likely leak in various ways (in the
>         user interface, browser history, etc.) that at the very least
>         cause user confusion about how URNs are used.
>
>
>     (note that there's no assumption here that there's any
>     intermediate URL that also refers to the document, though there
>     might be.)
>
>     2. A URN from a namespace which uses p-components is associated
>     with, and/or resolves to, either an HTML document or a service
>     that produces an HTML document when it is accessed.   That HTML
>     document contains one or more relative URIs that contain "paths"
>     that will, in the context of that HTML document, be evaluated
>     relative to the URN used to access or obtain that document. Again,
>     those relative URI references will leak in various ways that will
>     likely cause confusion.
>
>     3. A URN from a namespace which uses q-components is associated
>     with, and/or resolves to, either an HTML document or a service
>     that produces an HTML document when it is accessed.   That HTML
>     document contains either one or more relative URIs that contain
>     "queries" and/or one or more HTML forms which use the GET
>     method.   In order to submit the form, the client reading the HTML
>     document will construct a URI from the base URN and the form
> discussed. As it stands today, relative resolution with regards to 
> URNs is problematic at best. If your assertions are correct, this 
> confusion would only break something that is already broken.

I haven't tried to do the entire case analysis of what happens when you 
try to resolve relative URIs with reference to base URNs of either the 
2141 or 2141bis sort.   It would probably be instructive to do so.

(For instance, I now find myself wondering, what if a resource that's 
referred to by both URN N and URL L contains a link to a relative URI 
"?x"?   The interpretation with respect to base URI L is well-understood 
- it means send "x" as a query to the resource.    But if we apply 3986 
rules for relative URI processing and 2141bis rules for interpretation 
of the result, it potentially means something entirely different, and 
the meaning is namespace-specific.   Similarly for references to 
relative URI "#y".)

In the meantime, I suspect that use of any relative URI with a RFC 2141 
base URN either produces a reference to a fragment in the same resource 
in which it appears, and/or a query of the same resource in which it 
appears.   (it could also refer to a fragment of the query result).   If 
the relative URI only affects the "path", at most it's replacing the 
base URN's NSS with the text from the relative URI. Assuming anybody's 
actually relying on this (which I doubt), it's not going to break 
persistence - it's just a shorthand way of referring to another URN 
within the same namespace.   But once you try to apply relative URIs to 
URNs with p-components, you then build an expectation into the resources 
named with those URNs, and using those relative URIs, that the URNs 
within that particular namespace are assigned according to some 
structure in which the p-components form a hierarchy, and not only the 
entire URN but also every enclosing subtree of that URN's "path" is 
persistent.   That's fine if a particular namespace wants to assume that 
burden, but failure to do that breaks URN persistence.

>     4. A URN is used to identify a service which is accessed using
>     HTTP[S]. That service accepts query parameters using RFC3986
>     syntax.    With the current 2141bis language, there is no way that
>     a client, user, or document author can reliably construct a URI
>     which is a composition of the URN used to identify the service and
>     the query parameters.   If that client, user, or document author
>     happens to know how that particular namespace's resolver works,
>     that person might be able to construct such a URI - but those
> I guess we have not discussed the issue of generic URN resolvers (or 
> if we have, its been done at an abstract level). Maybe this working 
> group should explicitly discuss if considerations for generic URN 
> resolvers are relevant. In my message from the other day, I noted that 
> I could not find any implementations of a generic URN resolver. Given 
> that, do you believe we have an obligation to continue with 
> requirements for such software?

I certainly believe personally that that work needs to be done, and over 
the past few days I've been thinking (once again) about how to do it.   
I've considered writing up a draft specification for it, just in case 
it's useful to this WG as a proof-of-concept.   (one thing I've recently 
realized is that conditions today are MUCH more amenable to developing 
and deploying such a service than they were in the late 1990s)

Whether this particular WG should try to define requirements or write a 
specification for such a service is a question for IESG, since it's not 
in the current WG's charter.   (Of course if this WG doesn't want to 
take on that work, IESG is unlikely to ask it to do so.)

>
>     5. A URI or other string is constructed by adding one or more f-,
>     p-, or q- components to a base URN, following RFC 3986 syntax.  
>     It's not clear from 2141bis -10 whether the resulting string is
>     persistent or not, and this might vary on a per-namespace basis.
>
>
>     6. Users who are familiar with HTTP and other URLs will see '#',
>     '/', and '?' in URNs and think they know what these mean, think
>     they know how to manipulate them.   (There's been a tremendous
>     amount of misunderstanding about URNs, even within IETF, which has
>     hampered the actual utility of URNs even by those who understand
>     them.)
>
>
>  What types of users are you referencing? End users? Programmers? 
> Protocol specifiers? This is just my opinion, but I would guess that 
> end users have no idea what these different components mean or do and 
> they never will. My experience with URI libraries tells me that 
> programmers will also be in the dark for sometime to come*. And we 
> know that protocol authors have asked for these changes.

I never cease to be amazed at just how much a great many "ordinary" 
people know about subjects like HTML, CSS, URLs, JavaScript, SQL, PHP, 
and so on.   (Though I don't know why this surprises me - many people 
who aren't mechanics know a decent amount about, say, automobiles and 
engines, and the web is as much a part of most of our lives as driving is.)

I suspect that at least some of those "ordinary" people also will want 
to know how to use URNs, including how they interact with fragments and 
queries and relative URIs, especially if URNs can make the internal or 
external links in their web pages more reliable.

IMO, our goal should be to make URNs so predictable, and so obviously 
useful, that browser vendors will want to include support for them in 
their products.   And given that there aren't that many different 
browser codebases in widespread use, this shouldn't be a terribly 
daunting task.

>
> -andy
>
> * Aside: I know the IETF says it does not do APIs, but a URI/URN 
> reference API would probably have been a good thing. The state of URI 
> libraries is a mess, whereas the APIs for sockets are in much better 
> shape and are very similar from one language to another.

agreed.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Apr 2015 03:12:24 -0400

--On Wednesday, April 01, 2015 15:32 -0400 Andrew Newton
<[email-masked]> wrote:

> <[email-masked]> wrote:
> 
>>  Regarding 3986 in general, I recognize that there's a
>>  conundrum here. As I understand things, the AD explicitly
>> imposed 3986 syntax on this group.

I don't think the AD is to blame.   In some sense, the community
did that when RFC 2396 was approved and it did not remove URNs
from 3986 when it replaced 2396.

>> So I undertand that the
>> group has a hard time recommending a different approach.
>> Also, much of the group has long believed that 3986 is
>> adequate, and maybe there's already some use of that syntax
>> in deployed URNs, so there's a lot of inertia behind that
>> syntax.

I'm not sure I understand what the above is intended to tell us.
As far as I can tell, anything that conforms to the syntax of
RFC 2141 conforms to that of 3986.  Probably even most of the
semantics are ok too.  Issues arise only one when starts
expanding syntax beyond 2141, even if it is done in ways that
2141 clearly anticipated (although, as you point out, didn't
do... whether because people couldn't agree on parts of the
issues or for other reasons).

> There was a proposal before the working group to complete
> separate URNs from 3986, and it was the working group decision
> to adhere to 3986 syntax but to let go of 3986 semantics. Many
> pointed out that in today's world, URNs do appear in places
> where URIs are expected (XML namespace specifications are a
> great example).

>> So, regardless of what I personally believe, I'm not really
>> trying to persuade you or the group that 3986 should be
>> abandoned.    I do, however, think that, having decided to
>> use that syntax (or having had that syntax imposed on it),
>> the group has to solve the problems that result from that
>> decision before it can expect its document to be approved as
>> a proposed standard.

I certainly agree with that.  However, if the WG sticks to its
"adhere to 3986 syntax but avoid getting entangled with 3986
actual or implied semantics and arguments about them" position,
I think those problems are actually quite few.   They include
issues with %-escapes and canonicalization for characters that
3986 does not allow to appear in non-encoded form (either
generally, as in non-ASCII characters, or in specific contexts,
such as some delimiters).  For canonicalization (including
normalization) we could in principle decide to do something
scheme-wide or could push the problem down to the NID and
namespace, but I agree that we need to decide.  Similarly, I see
no way to avoid deciding what to do about relative resolution
but possible decisions could, I believe, lie anywhere in the
range from "trying to do relative references with URNs will
cause pain so don't do that" to "if you don't want relative
references as specified in 3986, don't allow a '/' character
(and hence a p-component) in the obvious place in a URN".

>> I continue to believe that the decision to use that syntax
>> will result in a tremendous amount of harm and confusion,
>> because it's using a syntax that people are accustomed to
>> using with http and other URLs, but in very different ways -
>> and perhaps even in ways that vary arbitrarily as far as
>> users are concerned.

I actually agree with that.  You and Larry probably remember
that I expressed some concerns about creating a family of URIs
and declaring that URNs were part of it in the first half of the
1990s.  I would have preferred at that point that "name"-type
things be distinguishable in basic syntax from "locator"-type
things such that they could evolve separately and so that any
protocol or context that wanted to support both would need to do
explicitly rather than as an accident of similar syntax.  I was
obviously in the rough.  I think you were on the winning side.
But the discussions of the last few years, especially those
associated with trying to minimize collateral damage from 3996,
have convinced me I was probably right. That is _extremely_
scant comfort because the only way I can imagine getting to that
point would be to essentially abandon URNs, develop some other
scheme and non-URI syntax, and try to persuade those responsible
for protocols that use both to provide for the new syntax.
Even if I were convinced that was the right thing to do (and I'm
not), I think the odds of the community accepting it are
extremely low... just about zero.

>>   But at least for the time being,
>> that's irrelevant unless/until either IESG rejects the
>> document (perhaps realizing that the result just creates too
>> many problems) or an AD or IESG action gets overturned on
>> appeal.

> How do we quantify that type of harm? Especially against the
> knowledge that we will break many things currently in use
> today if we do not adhere to 3986 syntax?

I agree with Andy's question but let me ask a different one.
Suppose the WG continues on its current path and reaches
(probably very rough) consensus on something that appears to be
syntax-conformant to 3986 and still meets the claimed needs of
various communities for extended capabilities in URNs.  Suppose
that consensus solution is rejected or (ignoring a small detail
of the appeals model) overturned as you suggest above.   What do
you see happening after that?  What would you like to see
happen?    

My guess is that the IESG would throw up its collective hands in
despair and frustration and give up (not unlike the way it gave
up on IRIs).  The people whose needs are met by 2141 would
continue to conform and point to 2141.  The people who believe
they need extended functionality and syntax beyond what 2141
allows conclude that the IETF, having given up, can't constrain
their work any longer and essentially go off and do their thing,
using strings that start in "urn:", followed by things that look
like 2141-compatible NID and NSS strings, followed by some
decorations that might or might not look like 3986 URI
components.  Some of them might gather together and figure out
common ways to proceed, but that wouldn't be the IETF's problem
(and certainly not under IETF control) whether they ended up
with one such common way or with different communities and
different approaches.    Oh, and because the registration
procedure for formal NIDs would remain IETF Consensus (as
specified in RFC 3406) and these same arguments, plus arguments
about 2141-conformance, would almost certainly break out any
time someone tried to get a formal NID assigned that used
enhanced (beyond 2141) capabilities or syntax, few of those
would be registered and we'd almost inevitably end up with
either a registry in Wikipedia or the like (but not IANA) or
conflicts in which the same string was used as an NID to refer
to different namespaces.

Now, perhaps there are people in the WG who consider the above
scenario a good outcome.  If so, I wish they would speak up
because, if that position represents WG consensus, we could save
ourselves, the community, and the IESG a lot of energy by just
giving up now and letting things take their course.

Or perhaps you see plausible scenarios that avoid that one.  If
you do, please share.

>> So basically I think the immediate task before us is to clean
>> up the messes created by RFC 3986 and the decision to allow

Should I take that to mean that you are, ultimately, just
opposed to allowing those additional syntax elements in URNs and
believe that we should stick to the syntax allowed by 2141,
changing things that it reserved for future extension to
permanent prohibitions? If so, that should be a relatively easy
issue on which to ask the co-chairs to initiate a consensus call
so we can at least focus future discussions and, if appropriate,
stop struggling with a number of very problematic and complex
specification tradeoffs and text.

>>  --On Thursday, March 26, 2015 11:58 -0400 Keith
>>  Moore<[email-masked]>
>>  <[email-masked]> wrote:
>> 
>> 
>> ...
>> 3. A URN from a namespace which uses q-components is
>> associated with, and/or resolves to, either an HTML document
>> or a service that produces an HTML document when it is
>> accessed.   That HTML document contains either one or more
>> relative URIs that contain "queries" and/or one or more HTML
>> forms which use the GET method.   In order to submit the
>> form, the client reading the HTML document will construct a
>> URI from the base URN and the form parameters using RFC 3986
>> "query" syntax.
>>  
> In a previous discussion on this list, relative resolution of
> URNs was discussed. As it stands today, relative resolution
> with regards to URNs is problematic at best. If your
> assertions are correct, this confusion would only break
> something that is already broken.

See comment about relative resolution and the need to decide
_something_ (which, to add to that list, could be to prohibit
both p-components and relative anything, scheme-wide).  The text
in 2141bis-11 largely reflected Graham's comments and insistence
on URN support for relative resolution but did so in the absence
of comments from anyone else.  The text is the best we could do
given comments on the list -- I don't consider the issue closed
until the co-chairs tell me/us it is.

>> 4. A URN is used to identify a service which is accessed
>> using HTTP[S]. That service accepts query parameters using
>> RFC3986 syntax.    With the current 2141bis language, there
>> is no way that a client, user, or document author can
>> reliably construct a URI which is a composition of the URN
>> used to identify the service and the query parameters.   If
>> that client, user, or document author happens to know how
>> that particular namespace's resolver works, that person might
>> be able to construct such a URI - but those assumptions fail
>> with generic resolvers.

> I guess we have not discussed the issue of generic URN
> resolvers (or if we have, its been done at an abstract level).
> Maybe this working group should explicitly discuss if
> considerations for generic URN resolvers are relevant. In my
> message from the other day, I noted that I could not find any
> implementations of a generic URN resolver. Given that, do you
> believe we have an obligation to continue with requirements
> for such software?

Personal hypothesis: the community's cumulative set of decisions
to have URNs that never resolve, URNs that resolve to URLs
(possibly with a range of choice/selector functions), URNs that
resolve to other sorts of things in the category Keith calls
machine-parseable, URNs that resolve to other sorts of online or
on-net objects if there are such things, and URNs that resolve
only to physical (non-computer/ non-electronic) objects was the
end of generic URN resolvers that actually do anything.   I
imagine that one could construct a sort of stub resolver that
would look up NIDs and associated information and then pass the
entire URN off to some appropriate place or one that would look
up NIDs, determine a category from the above list, and pass the
URN off to the handler for that category.   I don't see either
of those stubs as having much value, but others may reasonably
disagree.  If we do believe those functions are important and
likely to be supported in libraries, etc., we'd better put some
serious effort into ensuring that the right tables of
information exist and are available online and that registering
an NID gets them appropriately and reliably populated.

>> 5. A URI or other string is constructed by adding one or more
>> f-, p-, or q- components to a base URN, following RFC 3986
>> syntax.   It's not clear from 2141bis -10 whether the
>> resulting string is persistent or not, and this might vary on
>> a per-namespace basis.
>> 

See my previous comment on how much we can usefully pin down
"persistence" at this stage.  I still think we need to discuss
it, but parts of that discussion are going to be quite difficult
unless I'm wrong and we really can define what we are talking
about.   

>> 6. Users who are familiar with HTTP and other URLs will see
>> '#', '/', and '?' in URNs and think they know what these
>> mean, think they know how to manipulate them.   (There's been
>> a tremendous amount of misunderstanding about URNs, even
>> within IETF, which has hampered the actual utility of URNs
>  What types of users are you referencing? End users?
> Programmers? Protocol specifiers? This is just my opinion, but
> I would guess that end users have no idea what these different
> components mean or do and they never will. My experience with
> URI libraries tells me that programmers will also be in the
> dark for sometime to come*. And we know that protocol authors
> have asked for these changes.

I certainly agree with the above, especially the part about what
end users know.   I would add that almost every end user who
thought he or she understood URIs (or even http URLs) and who
proceeded to try to construct one URL from another by stripping,
e.g., parts of the query or path and got a nasty and
incomprehensible error message has learned, perhaps too well,
not to mess with such things.

> * Aside: I know the IETF says it does not do APIs, but a
> URI/URN reference API would probably have been a good thing.
> The state of URI libraries is a mess, whereas the APIs for
> sockets are in much better shape and are very similar from one
> language to another.

I almost agree, but I think that attempts to build and implement
such APIs or even a reference implementation, especially for the
"generic URI" case, would mostly have exposed the difficulties
with treating 3986 as an implementation specification.
Independent of any other issues, it is full of "you can do zero
or more of the following long list of things" statements.
Unless it contains enough flags and indicators to make it nearly
useless as an API, any implementation of such statements is
ultimately a profile, not an implementation of the spec.  

best,
    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Apr 2015 04:57:18 -0400

--On Wednesday, April 01, 2015 17:49 -0400 Keith Moore
<[email-masked]> wrote:

> See above - introduction of new components to URNs is going to
> break things no matter what syntax is used, *especially when
> those components aren't even interpreted consistently from one
> URN to another*.

I think you are wandering in and out of URI-world in a way that
I'm having trouble forming a good picture about.  Probably my
fault, but...

This also goes to one of my difficulties with the design
philosophy of 3986 and its predecessors although I try to accept
them on their own terms.   In the environment in which I learned
about human-computer interface design, when a user told a
computer system to do something, she was assumed to have a
reasonable expectation that either the instruction would work or
there would be a comprehensible explanation of why not.   Having
systems simply and silently discard anything they didn't
understand or want to deal with was considered, not merely
"broken" but seriously bad design.

But 3986 doesn't work that way.  To save someone having to
explain it to me, one of the reasons for its not doing so is
that the URI-interpreting routines may have no way to
communicate with the user, making reliable delivery of a clear
error or warning message impossible.  From the standpoint of
what I was taught in my youth, such statements are just symptoms
of more fundamental bad system design, on a par with the sudden
appearance of blue screens with "you lose" displayed in small
letters on them.

To use an illustration from one of Larry's notes, if one
specifies a fragment (sic) with a a "mailto:" URI, nothing
useful is going to happen.  Neither 3986 nor 4395bis impose
requirements for what the mailto handler/processor does with
that fragment: because there is, in general, no media type
associated with the resource, it can't use the thing, but those
specs are indifferent to whether the fragment is silently
discarded, an warning message is produced somehow and the email
message opened and sent anyway, or an error message produced and
the email system not involved at all.  4395bis doesn't even
provide a place in the relevant templates, etc., for the scheme
definition to announce how it handles (or expected mail
interfaces to handle) such things.

We could push Larry's example a bit an contemplate a forwarded
or other message with multiple body parts and a fragment
identifying one of the body parts.  Certainly MIME messages and
body parts have media types -- they were the environment for
which what are now called media types were intended.

Similarly, one could imagine a straightforward HTTP URL with a
fragment identifier that might just have nothing to do with the
relevant media type and content.   Again, it is up to the local
interpreter that deals with the retrieved file what to do with a
non-matching or irrelevant media type: warning, error message,
or silently discarding the fragment identifier.  The scheme
description for the "http" scheme does not impose a requirement
and, more important, 4395bis and its predecessors don't require
it to do so.

My opinion about this behavior is largely irrelevant: it is how
things work.   And, to the extent to which users understand what
is going on at all, they understand that, if a fragment (and I
am going to talk about fragments, complete with 3986 semantics,
in this example) is specified and doesn't match (for whatever
reason) or do what they expected (for whatever reason), they may
not get much information and may indeed have to guess what
happened to the fragment from whatever behavior they observe.  

Now, coming back to URNs, suppose we have a namespace with NID
"examplefrob".  And suppose someone writes:

   urn:examplefrob:tom#foot

Now, if that were interpreted by a namespace-sensitive routine
and it knew that the "examplefrob" NID and namespace was purely
2141-conformant, the URN above would be a syntax error that it
might report.   If, instead, the URN processor ("generic
resolver") were strictly 2141-conformant, the above would also
be a syntax error _even if the examplefrob NID and namespace had
a meaningful interpretation of fragments.  So the first issue is
that the user can't tell the difference between the two cases
and the second is that, as with many other kinds of extensions,
a user who tried to process a new extension through a legacy
system that is hostile to extensions is probably going to be
unhappy.

A third case would be a URN processor that is loosely conformant
to 2141 that would look at the syntax, say "no fragments allowed
here" to itself, and silently discard "#foot", processing only
the NID and NSS.  Again, no information to the user. 

Now, if those cases are consistent with your definition of
"broken", then I think I understand what you are concerned
about, except (i) that definition makes it impossible to extend
URNs at all and (ii) it is broken behavior with which most URI
users have become tolerant (because they have no choice).  

Now this gets more interesting for the URN case if one posits
  urn:examplefrob:harry#foot

Same NID as above but the fragment ID is valid for the "tom"
case but not for the "harry" one because Harry has no feet.  We
can quibble about whether tom and harry should have the same
media type but there is no possible URI requirement that their
media types be different (at this point, you and I could have a
conversation about media type parameters and their relationship
to the situation, but let's skip that).  Again, as far as the
user is concerned, the fragment identifier is going to work
sometimes and not others, what happens when it doesn't is not
really a function of either the scheme or the namespace, and
some perfectly legitimate versions of "not work" are going to be
indistinguishable from "fragment never accepted" or "old
processor".  Moreover, if the user has only the "harry" URI
above, she is likely to have no way to distinguish between
"fragments are never permitted for scheme 'uri'", "fragments are
never permitted for namespace 'examplefrob'", "the fragment
'foot' doesn't match or doesn't apply to NSS = 'harry' in the
'examplefrob' namespace", and "legacy URN processor/ generic
resolver".

For completeness, one might also have a different namespace that
never allows fragments.  Again, the user can't distinguish among
the several different cases.

It is pretty easy for me to argue that set of scenarios are
equivalent to "broken" but the brokenness is in the fundamental
URI design, not anything special to the URN case.  For any user
who has accepted (or just gotten used to) the operational
implications, this range of URN examples are just no different
from the assorted traditional URL cases.  So I don't understand
what is likely to be seen as broken or damaged here in practice
that isn't already present in how URIs work  Even the
distinctions between "allowed or prohibited by scheme" and
"allowed or prohibited by namespace" are likely to be invisible
to the user.

    best,
     john

---

From: Keith Moore <[email-masked]>
Date: Thu, 02 Apr 2015 14:32:01 -0400

> from 3986 when it replaced 2396.

I'd rather not think in terms of "blame".    But I think that most of us 
understand, at some level, that 3986 is broken with respect to URNs 
(though we may not agree on the degree of brokenness or the specific 
ways in which it's broken).    Absent AD direction, this WG could expect 
to have a fairly free hand in correcting that brokenness, since one 
Proposed Standard can update another.    With the AD dictating a 
particular direction, that's a tad more difficult.

> I think those problems are actually quite few.
I think the number of problems that you end up with depends a great deal 
on how you address those problems.   Some solutions leave more loose 
ends than others.

>     They include
> namespace, but I agree that we need to decide.
yes.

> Similarly, I see

I think it's a bit thornier than that, because relative URIs affect not 
only paths but also fragments and queries.

> 1990s.

I think most of us working to define URNs wanted them to be usable in 
most of the contexts that URLs were usable in, which implied at least 
some commonality in syntax between the two.   In my mind, it would have 
been sufficient to say that the syntax for URN and URL prefixes was the 
same, and the set of characters allowed in each is the same, so that a 
parser could always tell where the URN/URL was terminated.   (in those 
days, people cared a lot about being able to distinguish URNs/URLs from 
surrounding text, and of course this is still useful.)

The parts of 3986 that seems dubious to me are: trying to shoehorn URNs 
into the HTTP URL syntax (thus limiting the types of modifiers that 
could be applied to URNs to the set that could be applied to HTTP URLs, 
even though URNs need at least one additional type of modifier), 
effectively imposing the HTML notion of fragments on all URIs,  and 
imposing the HTML notion of relative URLs on all URIs. (Though in some 
sense the last bit of damage was already done as soon as HTML and its 
notion of relative references were widely adopted.)

> I would have preferred at that point that "name"-type

I think that even if we did that, we'd end up with many of the same 
problems.  We'd still want these new identifiers to be usable in some of 
the contexts that URLs are usable in.   We'd still want them to be 
compatible with HTML documents and their relative references.

> up on IRIs).

My guess is similar to yours, though I'm not sure whether IESG or the WG 
does that first.   The only way I see a different result is if the WG 
really does manage to figure out a sound solution to these problems so 
that it can go to IESG and say:  "We now thoroughly understand what we 
need to do, please let us do it. "

Earlier this morning I was thinking that the problem was that the 
majority of people in IETF don't understand the value of curated name 
spaces, and that a large constituency (mostly outside of IETF) that does 
understand that, doesn't necessarily understand network protocols and 
the web and all of the various ways that URIs interact with them.    
Problem is, URNs really do need to be worked out by people who have a 
good understanding of both, or at least with input from both sets of 
people.   And while I think it hasn't done such a good job so far of 
getting both sets of people in the same "room" (real or virtual) and 
getting them to understand each other, IETF probably is still the best 
place for that to happen.   At least I don't know of a better place.

> specification tradeoffs and text.

No, that's not my position at all.   Ultimately what I want is to make 
it feasible to build general-purpose resolution services, to be able to 
write software that resolves URNs in a general manner (without having to 
wire-in namespace-specific dependencies that potentially change every 
time a new namespace is created), to be able to use URNs to refer to 
network-accessible resources in HTML and other documents where URLs are 
used (including compatibility with relative references and the ability 
to bundle URNs with queries and/or fragments), and for browsers and 
other clients to be able to support URNs wherever that makes sense.

My only purposes in raising the "these problems didn't exist in 2141" 
points is to illustrate that the changes introduced in 2141bis really 
have created additional problems that need to be addressed, and to point 
out how 3986 constrains how we can address those already-difficult problems.

> end of generic URN resolvers that actually do anything.

I don't think so.   I think all that's required to have a generic URN 
resolver is to be able to do a database query for a URN. Basically that 
means being able to parse a URN, canonicalize it (if that's needed), and 
separate the components of the URN that aren't significant for 
resolution from those that are.   That database can then do one or more 
of the following with the significant portion:

  * say it doesn't know anything about that particular URN
  * list other services that might provide information about URNs with
    that particular namespace (or some narrower set)
  * return bibliographic citation information for the resource
    associated with that URN
  * return locations at which the named resource may be accessed and/or
    from which its contents may be retrieved
  * refer the client to other versions of the resource associated with
    that URN, or resources related to that URN
  * provide access to the resource and/or the content of the resource
    (when applicable)

One of the places at which we get into trouble with 3986 is that we'd 
really like to bundle together with the URN some information about which 
of the above results we want, and any other parameters that go with that 
request, and 3986 doesn't give us any way to do that without overloading 
syntax that is used for other purposes (including the relative 
references that are also described in 3986).

> I

While I'd love to see those tables compiled and made available, I don't 
think the resolution architecture should insist that any particular NID 
be limited to any of the above categories.   And I think that the less 
that URN handling software needs to be driven by externally-maintained 
tables, the better.

> unless I'm wrong and we really can define what we are talking

I think RFC 1737 is adequate.

As far as I can tell, the problem with discussing URN persistence is 
that lots of people come into the discussion with preconceptions based 
on the analogous concept that they've adopted in their own communities, 
or the specific problem that they want to solve.  URN persistence is 
deliberately a weak and vague notion of persistence, precisely because 
of the desire to be able to use URNs to name a wide variety of 
resources, whether or not network-accessible, whether or not implemented 
in code, whether or not based on data that can change over time (even 
continuously in some cases).   Other communities have adopted 
definitions and rules for identifier assignment that suit their own 
purposes, and they may have decades or even centuries invested in those 
definitions and rules.  As far as I can tell, that doesn't create a 
conflict with RFC 1737.  RFC 1737 sets a minimum requirement; it doesn't 
prevent individual URN namespaces from imposing more stringent requirements.

> not to mess with such things.

But they've also learned how to mess with such things, i.e. what works 
and what doesn't.

> with treating 3986 as an implementation specification.

Well, sure, there's no problem with any protocol specification until you 
actually try to use it.  :)
But that's what we do in IETF - we make protocol specifications with the 
expectation that they'll be used.

> ultimately a profile, not an implementation of the spec.
Only if we go down the path of permitting namespaces to use URN 
components in arbitrary ways.   And that's precisely why we should NOT 
do that, and to the extent we permit individual namespaces to vary from 
uniform behavior, we should make them a finite list of well-documented 
exceptions, not to be propagated to future namespaces.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Apr 2015 13:29:37 -0400

Ok, without trying to respond to this paragraph-by-paragraph:

One challenge we face in designing Internet protocols is arranging that 
the errors get reported to the people who are in the best position to 
fix them.   Sadly, lots of widely-deployed, successful protocols do a 
poor job at this, and the web is no exception.  But I don't fault 
browser vendors for failing to display an error message every time a web 
page contains what is essentially a mis-spelled URI, because the user is 
almost certainly not in a position to do anything useful with that 
information.  So in general, clients are going to do the best they 
can.   If the URI refers to a resource that can be displayed, they'll 
display it, even if the URI specifies a fragment that cannot be found.  
Of course, if the URI refers to a nonexistent resource, an error message 
is the most reasonable action for a browser.   Or if the URI contains a 
query that causes the service to respond with an error message, 
reporting that error message to the user is also reasonable for the 
browser to do.

URNs introduce the potential for new ways of being malformed but many of 
those kinds of errors, are essentially mis-spellings.   I don't think we 
can prevent people from mis-spelling URNs, and I suspect that browsers 
and other clients will generally do reasonable things for these cases, 
just as with URLs.   (There are of course web content verifiers that may 
try to detect and report such errors, which is appropriate as those have 
the specific goal of informing the content creator/maintainer about 
errors in the content.)   But in general: the maxim "garbage in, garbage 
out" applies, and absent some security or serious interoperational 
concern, we probably shouldn't get too worried about trying to specify 
what the output garbage looks like for malformed input.

Here are examples of the kinds of errors which I am more concerned about:

1. Inconsistent behavior (when given a correct URN) from one 
URN-supporting client to the next

Examples:

  * If clients need to know specific details about each namespace (e.g.
    how {f,p,q}-components are interpreted) in order to process URNs for
    that namespace, and those details are subject to change over time,
    it's reasonable to expect that there will be namespaces for which
    client A knows how to deal "properly" but client B does not.   So
    client A will interpret urn:example:foo/bar?zot#mumble in one way
    (because it knows the specifics for interpretation of URN
    "example"), and client B will interpret the same URN a different way
    (because it does not know those specifics).   As a concrete example,
    perhaps client A will know that for the "example" namespace,
    f-components are interpreted by presenting them to a resolver that
    is specific to the example namespace, and that resolver will then
    either return the content corresponding to that f-component or a
    link to such content.   But B, not knowing that "example" URNs need
    special treatment, may consult a generic resolver, may not include
    the f-component in its query to that resolver, may try to process
    the f-component as if the URN were an ordinary URL, etc.

  * Similarly, if a resolver has to know specific details about each
    namespace to function (like whether f-components are significant for
    resolution) it's somewhat more difficult to build generic resolvers
    that can interface to databases of information that span multiple
    URN namespaces.

2. Inconsistent behavior between when a resource is referred to via a 
valid URN, versus referred to by a valid URL that points to the same 
resource

Examples:

  * If a resource contains a relative reference, say to a different path
    or query or fragment than the original URI that led to the resource,
    and that reference is used, the way 3986 is specified, evaluating
    that relative reference results in a new URI that replaces
    components of the base URI with components derived from the base URI
    and the relative reference.  If, say, the resource contains a link 
    to "#foo", then "#foo" will replace any fragment (if the base URI
    was a URL) or f-component (if it was a URN).   Now, if
    interpretation of f-components in the new URN is different than
    interpretation of fragments in the new URL, dereferencing "#foo"
    will produce different results in the two cases /even when #foo is
    valid//and both of the derived URIs are valid/.   Similarly for
    relative references that affect p- or q-components.
  * A client might have two different potential ways to present a
    resource named by a URN: (1) request the resource content from a
    resolution service, (2) request a URL for the same resource content
    from a resolution service, then request the resource content using
    that URL.   For reasons illustrated above, the effect of
    dereferencing "#foo" could be different depending on which of (1) or
    (2) is used.
  * A user reading a document obtained using a URN might wish to
    "bookmark" that document or specific information within that
    document.   It's hard to say exactly what the user interface should
    be in this case, but especially when the user wishes to bookmark a
    specific portion of that document, it would make sense for the
    client to associate that bookmark with a URI that is associated with
    that specific version and rendition of the document - as opposed to
    a version- or rendition-independent URI.   Again, if the meanings of
    {f,p,q}-components can change from one URI of the same resource to
    another, this might defeat the ability to do reliable bookmarking,
    as the URI chosen by the client as a version-specific URI, might be
    different than the one originally used.

3. Behavior associated with a valid URN, that yet changes over time - 
perhaps because client handling of that URN's namespace changed (the 
namespace changed its behavior to support {f,p,q}-components, or the 
client started supporting that behavior), or perhaps because the method 
of resolution of that URN changed (say from resolving via an 
intermediate URL to resolving directly to the content)

The whole point of URNs is to facilitate stable references.   If someone 
creates some content with links to URNs and those links work with a 
properly functioning client when the content is created, those links 
should continue to work as long as resolution services are available.   
So behavior of a particular namespace with respect to URN components 
shouldn't be allowed to change, nor should behavior change depending on 
the specific way that a resource is resolved (assuming that the RFC 1737 
persistence rule is followed).

Of course there will be buggy clients, and hopefully also fixes to buggy 
clients, which will change behavior over time.   And the user interface 
in a particular client might also change, especially as the 
understanding of how to best interface to URNs and the resources named 
by them evolves.   But if the specifications don't facilitate stable 
references, so that properly-written clients can't produce consistent 
behavior over time, we're the ones who will have failed.

Keith

On 04/02/2015 04:57 AM, John C Klensin wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 07 Apr 2015 21:41:18 -0600

On 3/31/15 3:19 PM, Keith Moore wrote:

<snip/>

> 3.   In the hopes of clarifying further discussion, I offer the
> following definitions and goals:
>
> a) A general-purpose URN resolution service is a service which can
> potentially be queried for information about any URN, independent of
> namespace.   Multiple, independent general-purpose URN resolution
> services can potentially coexist.   Such a service might or might not be
> able to return information about that particular URN - there's no
> requirement that the service has a complete database of all URNs.   Such
> a service might or might not be able to delegate that query to one or
> more other services, based on the URN's namespace ID and/or information
> within that URN's NSS, but there's no requirement that the service know
> how to delegate to a resolution service for every namespace or other
> subset of URN-space.
>
> b) A general-purpose URN resolution client is one that can consult one
> or more general-purpose URN resolution services in order to attempt to
> obtain desired information about a URN when applicable, such as its
> citation/catalog information, network locations, content of the
> resource, etc., and which is not inherently limited to use with URNs of
> specific namespaces.
>
> I claim that generic resolution services and generic clients are
> desirable and anticipated by the URN work.

I respectfully suggest that, if there were demand for generic URN 
resolution services and generic URN clients, a supply of such software 
would have emerged sometime in the last 20 years (RFC 1737 was published 
in late 1994). As far as I know, that supply has not been forthcoming. 
What rational basis do we have for thinking that the next 20+ years will 
be any different?

> For example RFC 1727
> section 5 states "It may also be the case that there are generic ones"
> (i.e. resolvers or location services) "... providing service for many
> resources of differing naming authorities".   Indeed, a principal
> motivation for the URN work was to be able to resolve resource names in
> a generic fashion, even across potential changes in access protocols or
> lookup services.   (and this is precisely why we wouldn't have tried to
> divide URNs up into schemes like "ddds:" or "indicator:" - we were
> deliberately not taking that approach because doing so would harm URN
> persistence.)

And yet that motivation turns out not to have been shared widely enough 
for people to produce running code. In the absence of running code, we 
are left with theories and hypotheses and opinions, not engineering.

> RFC 2141 impedes neither of the above services [*].

Despite the lack of impediments, no software has been produced. We might 
take that as a sign that the issue doesn't matter in practice.

> But 2141bis -10
> impedes both of them, if the interpretation of f-components,
> p-components, or q-components by either the service or the client needs
> to differ from one namespace to another.   Note that it should *not* be
> expected that the resolution service is specific to a particular
> namespace, as there will be a need for resolution services that handle
> URNs from a variety of namespaces.  (if not immediately, then
> eventually, as the authoritative services for some namespaces will
> inevitably disappear, and there will be a desire to provide lookup
> services for URNs in namespaces that never had authoritative services.)
>
> If, on the other hand, all namespaces delegate evaluation of these
> components to a resolution service, that solves the problem to some
> degree, but it then presents other problems: e.g. evaluation of relative
> URIs with respect to these URNs, the inability to address fragments in
> HTML documents named by URNs, the inability to send "queries" using the
> HTTP GET method to resources that accept them (at least using an
> ordinary HTML tag), some namespaces won't have resolution services (thus
> there's no way for a client to know how to interpret their components)
> and so on.
>
> [*] RFC 2141 section 7 does say that "Functional equivalence is
> determined by practice within a given namespace and managed by resolvers
> for that namespace."   It may be the case that only an authoritative
> resolution service for a particular namespace can reliably determine
> functional equivalence for two URNs from that namespace, but generic URN
> resolution services are useful in other ways even if they cannot
> reliably determine functional equivalence.   (Note also that two URNs
> can be functionally equivalent even if they are from different
> namespaces; there's no requirement that all URNs for a particular
> resource be from the same namespace.)

Here again, to state that "generic URN resolutions services are useful" 
is entirely chimerical. We might as well be asking biologists to tell us 
what is true of unicorns.

I'm not saying that the points you raise are not interesting or 
important, but I am saying that they don't seem to me to make any 
difference with respect to the engineering decisions before us.

However, as always, I freely admit that I might be missing something.

Peter

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Apr 2015 01:52:12 -0400

Peter,

URNs are intended to be usable for centuries.   We've only been defining 
them for around 20 years, and most of that usage has been within 
specific communities using specific namespaces.   It seems very 
premature to declare the concept of general-purpose resolution services 
useless, or unneeded, based on existing software deployments.  It seems 
especially shortsighted to extend URNs in such a way as to preclude such 
services, or impose substantial barriers to their being created.

I was perhaps the first person to produce a web browser that could deal 
with URNs, and certainly one of the first to write a URN resolution 
service (with multiple service locations), both circa 1994.  At the 
time, those were extremely challenging things to do.   I couldn't buy 
servers in racks with network service, certainly not at commodity 
prices.   Hardware was relatively expensive and had very modest 
capability compared to today. Networks were much slower then than now: a 
1.5Mb/s T1 line was considered good connectivity then.   I had to rely 
on the good graces of other friends in academia to host remote servers 
and didn't have any administrative control over them.   There were also 
substantial challenges with implementation.   I tried three or four 
indexed file libraries and never found one that didn't either corrupt 
its files or leak core.   IN 1994, I was lucky enough to have an open 
source browser in Mosaic that I could modify to support a URN user 
interface and back-end.   But once Netscape became the popular browser 
there was no good way to support URN resolution in the browser for many 
years.  And there was really no library support above the level of BSD 
sockets with which to implement network protocols.   etc., etc.

These days, browsers have hooks to support additional URI protocols.   
Good libraries exist for node, python and several other languages to 
provide all of the network access, parsing, database support, JSON 
formatting, etc. that you could possibly need.    You can put together a 
decent server in a few hours. Reliable real and virtual servers are 
available in minutes, at commodity prices, with good network 
connectivity and good management.    So is cloud storage.

Defining such a service might still take a bit of thought to get the 
definition (close to) right, and collecting enough data for a usable 
general-purpose service might be tricky (others might know about 
citation database availability).   Setting up a sustainable revenue 
stream to keep such services running indefinitely might also be 
tricky.   But at least implementation of either the resolution services 
or client libraries shouldn't be much of a barrier these days.

It seems to me, for instance, that every library should be able to have 
a general-purpose service to allow its holdings to be queried by URN, 
even though the names might not all be from the same namespace.   
Similarly for every online book seller and its offerings, and every 
publisher.   What does that seem too you at all bizarre or unrealistic, 
or anything other than obviously useful?

Keith

On 04/07/2015 11:41 PM, Peter Saint-Andre - &yet wrote:
> would have emerged sometime in the last 20 years (RFC 1737 was 
> published in late 1994). As far as I know, that supply has not been 
> forthcoming. What rational basis do we have for thinking that the next 
> 20+ years will be any different?
>
>> For example RFC 1727
> And yet that motivation turns out not to have been shared widely 
> enough for people to produce running code. In the absence of running 
> code, we are left with theories and hypotheses and opinions, not 
> engineering.
>
> Despite the lack of impediments, no software has been produced. We 
> might take that as a sign that the issue doesn't matter in practice.
>
>> But 2141bis -10
> Here again, to state that "generic URN resolutions services are 
> useful" is entirely chimerical. We might as well be asking biologists 
> to tell us what is true of unicorns.
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 8 Apr 2015 12:30:57 -0400

Asking about keeping a generic URN parser as design criteria was next up on
my list, but I suppose Peter beat me to it. :)

On Wed, Apr 8, 2015 at 1:52 AM, Keith Moore <[email-masked]>
wrote:

> available in minutes, at commodity prices, with good network connectivity
> and good management.    So is cloud storage.
>

While such resources were not easily obtainable 20 years ago, they were 10
years ago. In that timeframe we have not seen generic URN services or
applications.

We need to allow uses of URNs from large URN-using communities as has been
requested vs. the desire for implementations that have had 20 years to
materialize but have not. While no person can predict the future, I would
guess the broader IETF community would favor changes to meet modern issues
over unrealized design criteria from 20 years ago.

-andy

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Apr 2015 12:45:38 -0400

On 04/08/2015 12:30 PM, Andrew Newton wrote:
> Asking about keeping a generic URN parser as design criteria was next 
> up on my list, but I suppose Peter beat me to it. :)
>
> On Wed, Apr 8, 2015 at 1:52 AM, Keith Moore 
>     These days, browsers have hooks to support additional URI
>     protocols.   Good libraries exist for node, python and several
>     other languages to provide all of the network access, parsing,
>     database support, JSON formatting, etc. that you could possibly
>     need.    You can put together a decent server in a few hours.
>     Reliable real and virtual servers are available in minutes, at
>     commodity prices, with good network connectivity and good
>     management.    So is cloud storage.
>
>
> While such resources were not easily obtainable 20 years ago, they 
> were 10 years ago. In that timeframe we have not seen generic URN 
> services or applications.

Again, you're not likely to see them until there's substantial use of 
URNs within multiple namespaces.   Deployment of something like URNs 
naturally takes place on a different time scale than deployment of, say, 
the web, which had immediate benefit to users even when it was small.    
And again, without some ability to generically process URNs, there's 
almost no value at all in having a URN URI scheme.

I also note that the URN resolution servers that I've discovered appear 
to be generic in some sense, in that they prompt for URNs rather than 
say ISBN URNs or NBN URNs.      So I don't think what we're seeing in 
this group's discussion is that actual users of URNs don't see the value 
in generic handling of URNs, but rather, that such actual users are 
under-represented in this discussion.

> We need to allow uses of URNs from large URN-using communities as has 
> been requested vs. the desire for implementations that have had 20 
> years to materialize but have not. While no person can predict the 
> future, I would guess the broader IETF community would favor changes 
> to meet modern issues over unrealized design criteria from 20 years ago.

This isn't a case of a conflict between modern issues vs. unrealized 
design criteria.

Keith

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 09 Apr 2015 21:29:29 -0600

On 3/31/15 10:52 AM, John C Klensin wrote:
> Keith,
>
> Interestingly, whether these are "nits" or not is itself an
> interesting question because each one seems to me to raise
> additional questions or issues.  We certainly agree that none of
> them are (or should be) earthshaking or showstoppers.  I/we have
> not incorporated changes for any of them into -11.  I suggest
> that you and the rest of the WG have a look at the comments
> below to see if we can reach conclusions about what should be in
> -12.  The numbering of subsections and summary titles below are
> intended to lower the odds of anything getting lost.
>
> (1) "Typically"
>> 1. Introduction, 2nd paragraph, first sentence.   Omit the
>> word "typically", or otherwise reword to avoid creating the
>> impression that it's ok to use URNs as other than persistent,
>> location-independent resource identifiers.
>
> My recollection is that we put "typically" in there to resolve
> other concerns and complaints.  They _may_ have been about
> whether "persistent, location-independent resource identifier or
> abstract designator" actually covered all of the reasonable
> cases.

That is my recollection - we were not sure that "resource identifier or 
abstract designator" was all-encompassing.

>  Could others comment on this?  Note that almost the
> same phrasing appears in the Abstract so, if it should be
> changed in the Introduction, it should presumably be changed
> there too.
>
> (2) "MAY" and "can"
>
>> 2. Section 3, paragraph following ABNF section: I would
>> substitute "MAY" for "can".
>
> After some list discussion (and, IIR, considerable confusion
> about what 3986 allowed), I chose "can" because this statement
> is a reminder about 3986-reality rather than a normative
> requirement (even a permissive one) imposed by this
> specification.    If your reasoning is different, please explain.
>
> (3) "Global uniqueness"
>
>> 3. Section 6, paragraph starting "With regard to global
>> uniqueness":    Just simply state that a single resource can
>> have more than one URN assigned to it.   It doesn't matter
>> whether those URNs exist for different purposes.

That is one example of why more than one URN might be assigned to the 
same resource. I suggest:

OLD
    However, a single resource can have
    more than one URN assigned to it for different purposes (for example,
    if a book were published in a monograph series, it could have both an
    ISBN [RFC3187] and an ISSN [RFC3044] assigned to it, resulting in two
    URNs referring to the same book).

NEW
    However, a single resource can have
    more than one URN assigned to it (e.g.,
    if a book were published in a monograph series, it could have both an
    ISBN [RFC3187] and an ISSN [RFC3044] assigned to it, resulting in two
    URNs referring to the same book).

>> Also
>> clarify that if there is no such thing as a distinguished or
>> preferred URN for a resource that can be inferred from looking
>> at the URNs.

That seems correct to me.

>> At least as far as the URN architecture is
>> concerned, all URNs are equally valid.   (If the resource
>> wants to specify which of several URNs is the distinguished
>> name for itself, that's a different matter.)
>
> This paragraph has been slightly rewritten in -11 to reflect
> Ted's comments.  I'd like the WG to have a chance to look at
> this and compare it to the approach you recommend before making
> further changes.

I think some slight rewording can address these issues.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 09 Apr 2015 21:38:44 -0600

On 4/8/15 10:45 AM, Keith Moore wrote:
> URNs within multiple namespaces.

As I understand it, there are millions of URNs assigned for ISBNs, 
ISSNs, and NBNs. I would call that substantial use.

> Deployment of something like URNs

That might be - it might have made more sense to establish separate URI 
schemes for ISBN, ISSN, NBN, etc. But that ship has sailed. There is 
definitely value in all those assigned URNs, even if we didn't really 
(in retrospect) need to have a separate URI scheme for URNs.

> say ISBN URNs or NBN URNs.

Resolution for URNs from some namespaces might be appropriate (ISBNs, 
ISSNs, and NBNs seem to fit the bill). But the list of registered 
namespaces is much broader:

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

It seems to me that URNs from many of those namespaces might never need 
to be resolved, in part because they function as "abstract designators" 
or indicators.

> So I don't think what we're seeing in

Again, that might be. But unfortunately many constituencies are 
under-represented here because so few people are participating. (I 
haven't seen anyone on this list talking about the needs of all the SDOs 
or near-SDOs that have registered URN namespaces, for example.)

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 09 Apr 2015 21:50:16 -0600

On 3/31/15 3:42 PM, Keith Moore wrote:
> John,
>
> Let's take a step back here.   I'm not asking for this group or this
> document to revisit RFC 1737s definition of persistence. Nor do I think
> it is in scope for this working group (as defined by its charter) to do
> so, as that's tantamount to redefining URNs.
>
> I'm simply asking for one or two sentences to be added to rfc2141bis to
> clarify which of f-component, p-component, and q-component are relevant
> when considering persistence.   RFC 2141 didn't need to address this
> issue because with RFC 2141 URNs, the entire URN was assigned, so the
> persistence property applied to the entire URN.
>
> The text I have in mind is something like:
>
> Only the [list of components] of the URN are required to meet the
> "persistence" property specified in RFC 1737.   Individual namespaces
> may, however, impose more stringent requirements on use of [other
> components].
>
> I just don't know what should be that list of components.  I can,
> however, somewhat arbitrarily, suggest concrete text:
>
> Only the assigned-name and p-component of the URN are required to meet
> the "persistence" property specified in RFC 1737.   Individual
> namespaces may, however, impose additional restrictions on the use of
> q-component and/or f-component.
>
> (and if a normative reference to RFC 1737 is a problem, just leave out
> "specified in RFC 1737".   RFC 1737 would probably have been a BCP, had
> BCPs existed at the time.)

I think the persistence rule falls out from equivalence rule. If we say 
that only the assigned-name and the p-component are taken into account 
for purposes of determining equivalence, then I think we would say that 
only the assigned-name and p-component are required to meet the 
persistence property.

Peter

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 10 Apr 2015 00:00:17 -0400

> ISSNs, and NBNs. I would call that substantial use.

I should perhaps have been clearer about what I meant by "substantial 
use".   But I expect that by now there are some resolution services that 
accept URNs from any of these namespaces, and perhaps some other 
namespaces, without requiring the client to know particulars of each 
namespace and to process different namespaces differently.    And it 
actually appears that some such services exist.   Most of what I'm 
saying is that it should continue to be possible to have such services, 
not only for RFC 2141 URNs but also for URNs with an extended syntax.   
Having namespace-specific interpretation of f-, q- ,or p-components 
potentially threatens this property and makes it harder to build generic 
resolvers and generic client code.

Frankly, I don't understand why this isn't obviously important to 
everyone here, or what the disconnect is.

> That might be - it might have made more sense to establish separate 
> URI schemes for ISBN, ISSN, NBN, etc. But that ship has sailed. There 
> is definitely value in all those assigned URNs, even if we didn't 
> really (in retrospect) need to have a separate URI scheme for URNs.

I never argued that there shouldn't be a separate URI scheme for URNs.  
What I said was that extending URNs to have namespace-specific 
interpretation of fragments, paths, and/or queries defeats the purpose 
of having a URN scheme in the first place.  I assume that the purpose of 
the URNBIS group is not to defeat the purpose of having a URN scheme.  
It's not my purpose either.   If we're going to extend URN syntax, I 
want us to do it in such a way that it can work well.

> It seems to me that URNs from many of those namespaces might never 
> need to be resolved, in part because they function as "abstract 
> designators" or indicators.

I don't disagree with that, and nothing that I'm asking for contradicts 
that.   There's no requirement that every URN be listed in some resolver 
somewhere.  There will always be URNs for which one cannot obtain any 
information from any existing source.   This is understood.

When I say "generic resolver" I don't expect that any such resolver will 
have information for every URN, or even that there will be a resolver 
for every namespace.   What I mean is that it should be possible to 
write client and server software that can potentially process any URN 
(and say, query a database for it and/or provide access to its content, 
when applicable and when the content is available) without that software 
having to know specifics of that particular URN or namespace.    You 
shouldn't need to have to write separate client code for each namespace, 
or separate server code for each namespace.   This is the very purpose 
of protocol standards, and protocol standardization is what we are 
supposed to be doing here.

> haven't seen anyone on this list talking about the needs of all the 
> SDOs or near-SDOs that have registered URN namespaces, for example.)

Agreed, this is a big problem.

Keith

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Apr 2015 15:22:38 -0400

--On Thursday, April 09, 2015 21:50 -0600 Peter Saint-Andre -
&yet <[email-masked]> wrote:

>> Let's take a step back here.   I'm not asking for this group
>> or this document to revisit RFC 1737s definition of
>> persistence. Nor do I think it is in scope for this working
>> group (as defined by its charter) to do so, as that's
>> tantamount to redefining URNs.
>> 
>> I'm simply asking for one or two sentences to be added to
>> rfc2141bis to clarify which of f-component, p-component, and
>> q-component are relevant when considering persistence.   RFC
>> 2141 didn't need to address this issue because with RFC 2141
>> URNs, the entire URN was assigned, so the persistence
>> property applied to the entire URN.
>> 
>> Only the [list of components] of the URN are required to meet
>> the "persistence" property specified in RFC 1737.
>> Individual namespaces may, however, impose more stringent
>> requirements on use of [other components].
>> 
>> I just don't know what should be that list of components.  I
>> can, however, somewhat arbitrarily, suggest concrete text:
>> 
>> Only the assigned-name and p-component of the URN are
>> required to meet the "persistence" property specified in RFC
>> 1737.   Individual namespaces may, however, impose additional
>> restrictions on the use of q-component and/or f-component.
>> 
>> (and if a normative reference to RFC 1737 is a problem, just
>> leave out "specified in RFC 1737".   RFC 1737 would probably
>> have been a BCP, had BCPs existed at the time.)
> 
> I think the persistence rule falls out from equivalence rule.
> If we say that only the assigned-name and the p-component are
> taken into account for purposes of determining equivalence,
> then I think we would say that only the assigned-name and
> p-component are required to meet the persistence property.

FWIW, that is consistent with the assumption I've been making.
I've been concentrating on equivalence, but I believe the
definition of persistence in 1737, whose key phrase appears to
be "globally unique forever" (the other provisions cannot be
enforced except as a matter of intent) comes down to an
equivalence assertion about to what it is globally unique.

    john

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Apr 2015 15:34:44 -0400

--On Thursday, April 09, 2015 21:29 -0600 Peter Saint-Andre -
&yet <[email-masked]> wrote:

> That is one example of why more than one URN might be assigned
> to the same resource. I suggest:
> 
> OLD

Wfm.  Note, however, that draft-ietf-urnbis-ns-reg-transition
obsoletes 3044 and 3187 so we may want to either find other
examples or say something like "URNs based on ISBN [] and ISSN
[]" and then reference the ISO specifications.

>> this and compare it to the approach you recommend before
>> making further changes.
> 

Agreed.  This adds to the importance of other people speaking
up, ideally before Friday's interim meeting, rather than having
a discussion among Keith, Peter, and myself.

    john

---

From: "Hakala, Juha E" <[email-masked]>
Date: Tue, 14 Apr 2015 07:36:38 +0000

Hello,

Some comments below.

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: 13. huhtikuuta 2015 22:23
> To: Peter Saint-Andre - &yet; Keith Moore; [email-masked]
> Subject: Re: [urn] Persistence with f-components or p-components
> 
> 
> 
> --On Thursday, April 09, 2015 21:50 -0600 Peter Saint-Andre - &yet
> <[email-masked]> wrote:
> 

<snip>

> >> I'm simply asking for one or two sentences to be added to rfc2141bis
> >> to clarify which of f-component, p-component, and
> >> 2141 didn't need to address this issue because with RFC 2141 URNs,
> >> the entire URN was assigned, so the persistence property applied to
> >> the entire URN.

It is a good idea to provide more information about this.

> >> "persistence" property specified in RFC 1737.

This should do, although a more detailed discussion about this could be provided. 

> >> Only the assigned-name and p-component of the URN are required to
> >> meet the "persistence" property specified in RFC

+ 1

<snip> 

> > I think the persistence rule falls out from equivalence rule.

Equivalence is one way of deciding what should be persistent, and perhaps sufficient for RFC 2141bis. 

It is also possible to look at this from administrative point of view. Only the assigned name such as ISBN has (or should have) solid administrative basis. When users later add for instance f-components to URN:ISBNs in order to cite locations within e-books, they do that "at their own risk", even though an f-component added to a URN which identifies a single manifestation of a resource (such as a PDF version of a book) is likely to be more persistent than fragment added to a URL.

It would be awkward to require persistence of q-components, since resolution services available and whatever is being supplied will change over time. For instance, if a q-component requests metadata about a resource, the metadata record retrieved may change from one day to the next, and even the default metadata format supplied may change (from e.g. MARC 21 to Dublin Core). 
 
> > If we say that only the assigned-name and the p-component are taken
> > into account for purposes of determining equivalence, then I think we
> > would say that only the assigned-name and p-component are required to
> > meet the persistence property.

OK for me, but it might be a good idea to say that currently (most) standard identifiers out there do not allow usage of p-component, and it is necessary to investigate whether adding it would be useful. 

Juha

> I've been concentrating on equivalence, but I believe the definition of
> persistence in 1737, whose key phrase appears to be "globally unique
> forever" (the other provisions cannot be enforced except as a matter of
> intent) comes down to an equivalence assertion about to what it is globally
> unique.
> 
>     john
> 
> 
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 14 Apr 2015 11:35:33 -0400

--On Tuesday, April 14, 2015 07:36 +0000 "Hakala, Juha E"
<[email-masked]> wrote:

>> >> rfc2141bis to clarify which of f-component, p-component,
>> >> and q-component are relevant when considering persistence.
>> >> RFC 2141 didn't need to address this issue because with
>> >> RFC 2141 URNs, the entire URN was assigned, so the
>> >> Only the [list of components] of the URN are required to
>> >> meet the "persistence" property specified in RFC 1737.

Proposal, given changes already incorporated in -11 of 2141bis.
If the WG decides to undo those changes, something more drastic
will be needed.

	(i) Rename the present Section 4 to "Equivalence and
	Persistence of URNs".
	
	(ii) Add a new subsection 4.2, incrementing the number
	for the current 4.2 to 4.3, titled "URN Persistence"
	that reads:
	
	For consistency with the "persistence" property
	[RFC1737] and as a logical consequence of the
	equivalence procedure described immediately above, only
	the <assigned-name> (see Section 3 above) are
	necessarily treated as persistent.  Individual
	namespaces may, however, impose more stringent
	requirements on the use of q-components or f-components.

I'm not sure whether the final sentence above is needed or not
or whether, if we include it, it will touch off another battle
about what we are allowed to say about fragments.  It can,
obviously, be easily removed if it is more trouble than it is
worth.   Alternate phrasing and/or nit-picking welcome, but the
above ties persistence explicitly and strongly to URN
equivalence as Peter and I have suggested elsewhere. 

Is something like that sufficient for us to move on? Vis-a-vis a
more detailed discussion, I don't know quite what to say, so, if
more is needed, please send either text or a detailed outline
(or ask Melinda and Andy to put it on Friday's agenda).

>...
>> Individual namespaces may, however, impose
>> >> additional restrictions on the use of q-component and/or
>> >> f-component.
> 
> + 1

Incorporated into the above suggestion, but see the comment
there.

> It is also possible to look at this from administrative point
> of view. Only the assigned name such as ISBN has (or should
> have) solid administrative basis. When users later add for
> instance f-components to URN:ISBNs in order to cite locations
> within e-books, they do that "at their own risk", even though
> an f-component added to a URN which identifies a single
> manifestation of a resource (such as a PDF version of a book)
> is likely to be more persistent than fragment added to a URL.

That "administrative" explanation is the reason I've sort of
resisted making explicit statements about persistence in 2141bis
or elsewhere.   Clearly it would be possible to explain
persistence on that basis.  IMO, it would be more satisfactory
in some ways.  However, I don't believe that it would be
consistent with what RFC 1737 has to say.  I've got other issues
with that document, most of which come down to "we've learned
some things in 20 years", but really don't want to reopen if if
that can be avoided.
 
> It would be awkward to require persistence of q-components,
> since resolution services available and whatever is being
> supplied will change over time. For instance, if a q-component
> requests metadata about a resource, the metadata record
> retrieved may change from one day to the next, and even the
> default metadata format supplied may change (from e.g. MARC 21
> to Dublin Core).   

Yes.

>> > If we say that only the assigned-name and the p-component
>> > are taken into account for purposes of determining
>> > equivalence, then I think we would say that only the
>> > assigned-name and p-component are required to meet the
>> > persistence property.
> 
> OK for me, but it might be a good idea to say that currently
> (most) standard identifiers out there do not allow usage of
> p-component, and it is necessary to investigate whether adding
> it would be useful. 

Today, no standard identifier allows usage of any of p-, q-, or
f-component (although the "fragment" discussion may interact
with the latter) because such usage violates RFC 2141
restrictions.  Especially for established namespaces (and again
modulo the "fragement" issues), none of these qualifying
decorations should be added unless they are useful.  At least
without more clarity about which components serve which roles in
URN processing, evaluation, and/or resolution, p- and
f-components are, IMO, more likely to be problematic than
f-components (that has been said in the WG in various forms for
two years now).   How much of that do you think we need to say
explicitly?

best,
   john

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Apr 2015 11:59:20 -0400

> 	requirements on the use of q-components or f-components.

Absent the last sentence, I'm tentatively ok with this.   If we're going 
to permit bundling of URNs and "fragments" (in the sense that they 
currently exist) it seems safer to not require that the combination be 
persistent.

I'm not sure about the last sentence because I remain concerned about 
having interpretation of any of these components be specified on a 
per-namespace basis.    Also, if neither f-components nor q-components 
are part of the "assigned" portion of the URN, I'm not sure what a 
namespace has to say about them.

Keith

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 15 Apr 2015 21:02:06 -0600

On 3/31/15 3:15 PM, Keith Moore wrote:
> On 03/29/2015 10:41 PM, John C Klensin wrote:
>>
>>> 7.  I'm somewhat sympathetic to the idea that IETF Consensus
>>> is not the right template for creating new namespaces, but
>>> Expert Review is even worse.   I think we need widespread
>>> public review, and that our very experience in this working
>>> group is a good indicator of why - there is as yet no small
>>> collection of "experts" that really understands everything
>>> about what it takes to make URNs function well, especially
>>> when applied to network-accessible resources.
>> This issue has been discussed fairly extensively within the WG
>> and consensus to make the change to Expert Review was reached,
>> IIR, a couple of years ago.  The counterargument to "Expert
>> Review is even worse" is based on something we've seen played
>> out many times with media types as the best-known example.  If
>> we create a registration procedure that is perceived of as
>> onerous, the main effect is to encourage squatting (or whatever
>> one chooses to call using unregistered names) and perhaps having
>> some Wikipedia page over which the IETF has no control turn into
>> the registry that people consult rather than having an IANA
>> registry serve that role.  In that situation, we also often end
>> up with no useful documentation at all.  So the model in 2141bis
>> (somewhat revised for more clarity in -11 which we still expect
>> to have posted Tuesday or earlier) not only defines the Expert
>> Review process but makes it more consultative rather than
>> judgmental to encourage documentation and registration.
>
> 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.

Peter

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Apr 2015 08:28:52 -0400

On 04/15/2015 11:02 PM, Peter Saint-Andre - &yet wrote:
> 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.

(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.)

Keith

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Fri, 17 Apr 2015 13:09:16 -0400

Thanks for the nudge to this thread, which largely addresses my earlier 
comments about clarity in the document.

I do still feel that some words saying that "/" should be used iff one 
understands that one is intruducing p-components, and not as a simple 
syntactic conversion from existing namespaces.

(And, I do think the last sentence that you questioned is important).

Leslie.

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------