Subject: Re: [urn] Queries in URNs (was: AW: URN fragments)

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 3 Jun 2013 08:55:36 +0000

So, to sum up my understanding of the discussion so far (I write this as statements, please indicate if you agree or disagree with what I write):

1) Regardless if they make sense or not, there is agreement that queries in URNs are different from queries sent to URN resolution services (or in other words: Queries in RFC 2141 bis -- should we allow them -- are something completely different than queries in RFC 2483 bis.

2) We seem to disagree if queries related to URNs should be considered part of the URN or not:
Michael writes [1]:
[[
That language needs to be much clearer when it uses "part of" and "append to". What is being suggested is that you can include a query string along with a URN that you can then send to the resource but that DOES NOT make that query string part of the URN itself. It is a separate thing. There is no 'query part' to a URN. You can carry around a bag of characters with the URN that you send to the resource, and you can even specify a syntax for how you carry them around together, but the query string is still something that is evaluated by the Resource.
]]

Peter writes [2]:
[[
As stated, personally I would prefer not to make query components part of URNs, or to append query components to URNs themselves. If you want to pass a query component to a resolution service (e.g., via an HTTP URI for the resolution service), that's something quite different and it seems fine to me.
]]

Barry writes [3]:
[[
(1) Queries and fragments are valid URI syntax, and URNs are URIs.  It seems reasonable to syntactically allow them in URNs, if we can agree on what they semantically mean.
]]

The way I read RFC 3986 puts me more on Barry's side: Every URN is a URI and thus the URN syntax adheres to the generic URI syntax. Sec 3 of RFC 3986 says 

URI  = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

In my reading that makes query (and fragment) part of the URI and thus they must be part of the URN as well if we decide to allow queries in URNs. If we explicitly want to make queries something you add to a URN we must define it as

URN = "urn:" hier-part

leaving the query out.
Please apologise if I miss something obvious.

3) *If* we decide to allow queries in URNs the exact semantics of the query MUST be stated during the NID registration process and specified in the registration document; default is that queries are not allowed for a specific namespace. That way we don't break anything since all existing namespaces would need to re-register in order to use queries.

Is there agreement on this?

4) @Juha: you say that queries only make sense in the context of URN resolving. Does that mean that even if we allow queries in RFC 2141 bis, you would disallow them in RFC 3187 bis (urn:isbn) since they have no meaning for resources identified by ISBNs?

/Lars

***Lesen. Hören. Wissen. Deutsche Nationalbibliothek***
***Reading. Listening. Understanding. German National Library***

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 03 Jun 2013 21:28:12 -0600

On 6/3/13 2:55 AM, Svensson, Lars wrote:
> The way I read RFC 3986 puts me more on Barry's side: Every URN is a URI and thus the URN syntax adheres to the generic URI syntax. 

But that doesn't follow.

A URN is a URI with a scheme of 'urn'. Each URI scheme can define its
own syntax, as long as that syntax is consistent with the generic URI
syntax.

> Sec 3 of RFC 3986 says 

Section 3 of RFC 3986 also has this interesting summary:

   The following are two example URIs and their component parts:

         foo://example.com:8042/over/there?name=ferret#nose
         \_/   \______________/\_________/ \_________/ \__/
          |           |            |            |        |
       scheme     authority       path        query   fragment
          |   _____________________|__
         / \ /                        \
         urn:example:animal:ferret:nose

So, according to RFC 3986, a URN is a URI with only a scheme component
and a path component. And that is consistent with the syntax defined in
RFC 2141:

<URN> ::= "urn:" <NID> ":" <NSS>

> In my reading that makes query (and fragment) part of the URI and thus they must be part of the URN as well if we decide to allow queries in URNs. 

The operative word there is "if". :-)

> If we explicitly want to make queries something you add to a URN we must define it as
> 
> URN = "urn:" hier-part

That's wrong, because RFC 3986 says:

      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty

and:

      path          = path-abempty    ; begins with "/" or is empty
                    / path-absolute   ; begins with "/" but not "//"
                    / path-noscheme   ; begins with a non-colon segment
                    / path-rootless   ; begins with a segment
                    / path-empty      ; zero characters

      path-abempty  = *( "/" segment )
      path-absolute = "/" [ segment-nz *( "/" segment ) ]
      path-noscheme = segment-nz-nc *( "/" segment )
      path-rootless = segment-nz *( "/" segment )
      path-empty    = 0<pchar>
      segment       = *pchar
      segment-nz    = 1*pchar
      segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                    ; non-zero-length segment without any colon ":"

      pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

Thus, as far as I can see, the closest thing to the URN syntax
definition in RFC 3986 is:

URN = "urn:" path-noscheme

However, the syntax of the 'urn' URI scheme is even more restrictive
than that:

   <URN> ::= "urn:" <NID> ":" <NSS>

   <NID>         ::= <let-num> [ 1,31<let-num-hyp> ]

   <let-num-hyp> ::= <upper> | <lower> | <number> | "-"

   <let-num>     ::= <upper> | <lower> | <number>

   <upper>       ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
                     "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
                     "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
                     "Y" | "Z"

   <lower>       ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                     "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                     "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                     "y" | "z"

   <number>      ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                     "8" | "9"

   <NSS>         ::= 1*<URN chars>

   <URN chars>   ::= <trans> | "%" <hex> <hex>

   <trans>       ::= <upper> | <lower> | <number> | <other> | <reserved>

   <hex>         ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
                     "a" | "b" | "c" | "d" | "e" | "f"

   <other>       ::= "(" | ")" | "+" | "," | "-" | "." |
                     ":" | "=" | "@" | ";" | "$" |
                     "_" | "!" | "*" | "'"

> Please apologise if I miss something obvious.

See above.

> Is there agreement on this?

What code exists to parse URIs with the 'urn' scheme according to the
syntax defined in RFC 2141? Would that code break if the syntax
definition is liberalized?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Keith Moore <[email-masked]>
Date: Mon, 03 Jun 2013 23:51:48 -0400

I find this whole discussion somewhat pedantic, because it's much more 
important to describe the behavior when a system encounters a string like

urn:foo:bar?zot

or

urn:foo:bar#zot

than it is to decide whether the query string or the fragment are (or 
are not) part of the URN itself.

Having said that, I think it will only make things more confusing to 
change the URN syntax in RFC 2141.   And RFC 2141 doesn't allow either # 
or ? in the NSS.  Trying to "liberalize" the syntax will only break 
things in subtle ways.

So don't try to change the definition to make "urn:foo:bar?zot" a URN.   
Instead, call it something that's consistent with RFC 2141, like "URN 
with a query string appended", and describe how resolution works on such 
a contraption.

Keith

p.s.  Also, if 2141's description of URNs is inconsistent with 3986's 
description, 2141's is almost certainly more correct, and should take 
precedence.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 04 Jun 2013 08:48:46 -0600

On 6/3/13 9:51 PM, Keith Moore wrote:
> I find this whole discussion somewhat pedantic, 

One person's pedantry is another person's insistence upon good
argumentation. :-)

> because it's much more

I agree that the proponents of changing the URN syntax need to describe
how a URN or URI processor (or pre-processor?) would behave when
encountering what looks like a URN with a query component or a fragment
identifier component.

However, there are implications here for registration procedures, as
well (3406bis). Currently, someone who registers a namespace identifier
(NID) doesn't need to say anything about query components or fragment
identifier components within that namesapce. Would that need to change,
or would the meaning and handling of those components be covered only by
the syntax spec? Or would they be application specific? Could an
organization that manages a NID include those components in minted URNs?

> or ? in the NSS.  Trying to "liberalize" the syntax will only break

Agreed.

> with a query string appended", and describe how resolution works on such

That's what I'm recommending, as well.

> description, 2141's is almost certainly more correct, and should take

I don't think it is inconsistent with RFC 3986, but I do think it is
more tightly scoped (i.e., more strictly limiting the allowable
characters in the path component).

A more general observation: it is very difficult to call consensus in
small, less active working groups. In my opinion, that would lead us to
be cautious about making changes to the syntax, semantics, and NID
registration procedures without strong evidence of the need for those
changes and a clear description of migration issues and the possibility
of breakage. So far I have not seen that strong evidence with regard to
the query component. The argument for the fragment identifier component
might be a bit stronger, but let's have a separate thread about that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 Jun 2013 11:45:02 -0400

> One person's pedantry is another person's insistence upon good

Of course.  But I get the impression that people keep trying to specify 
resolution behavior in the presence of # or ? by nailing down exactly 
what is or isn't part of the URN.  I think it works better to specify 
resolution behavior by describing resolution behavior.
> identifier components within that namesapce.
That's ok, because the NSS prohibited by RFC 2141 syntax rules from 
containing either '#' or '?'  without their being percent-encoded. And 
if they're percent-encoded, the meaning of them is opaque to the client.

Also, query strings and fragment IDs are about resource content and 
presentation of that content, and it doesn't seem generally appropriate 
for a a URN namespace to constrain the content of resources.   That is, 
URNs and URN resolution are much more broadly applicable if URNs are 
independent of resource content.

>   Would that need to change,
No, they're prohibited from doing so (and creating the confusion that 
would inevitably result) by the URN syntax.   If we need to make that 
clearer, by all means let's do so.

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 04 Jun 2013 11:14:30 -0600

> if they're percent-encoded, the meaning of them is opaque to the client.

Are you suggesting that the maintainers of a namespace could include the
query string or fragment ID in the NSS for URNs in that namespace, with
"?" or "#" percent encoded? I'd be curious to hear what the proponents
of query strings and fragment identifiers would say about. Given that it
doesn't change the syntax from RFC 2141, I'd find that more palatable.

> independent of resource content.

Good point.

> clearer, by all means let's do so.

Well, there's the rub: as I understand it, the argument is that we need
to change the syntax of URNs to allow query strings and fragment IDs. So
"they're prohibited from doing so by the URN syntax" is true in the RFC
2141 world, but folks want to change the syntax in the 2141bis world...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Keith Moore <[email-masked]>
Date: Tue, 4 Jun 2013 13:30:27 -0400

> doesn't change the syntax from RFC 2141, I'd find that more palatable.

If you percent-encode # or ? in a URN NSS, it loses its special meaning.  It doesn't denote a fragment id or query string.

Really you shouldn't use percent encoding in URNs except when you're mapping some other kind of persistent identifier into URN space.

> to change the syntax of URNs to allow query strings and fragment IDs.

If what people want is to be able to refer to fragments of resources identified with URNs or to submit queries to resources named with URNs, then I think the answer is to define what it means to append a fragment I'd or query string to a URN - it means the fragment id or query string are ignored for resolution purposes, but interpret the fragment I'd or query string with respect to the resource after resolution.  Also, the URN is a persistent identifier but there is no assurance of persistence for the combination of a URN with a fragment ID or query string.

> So
> 2141 world, but folks want to change the syntax in the 2141bis world.

Those who don't understand URNs are doomed to reimplement them, badly.

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 04 Jun 2013 12:05:40 -0600

On 6/4/13 11:30 AM, Keith Moore wrote:
>>> Of course.  But I get the impression that people keep trying to
>>> specify resolution behavior in the presence of # or ? by nailing
>>> down exactly what is or isn't part of the URN.  I think it works
>>> better to specify resolution behavior by describing resolution
>>> behavior.
>>>>> because it's much more important to describe the behavior
>>>>> when a system encounters a string like
>>>>> 
>>>>> urn:foo:bar?zot
>>>>> 
>>>>> or
>>>>> 
>>>>> urn:foo:bar#zot
>>>>> 
>>>>> than it is to decide whether the query string or the fragment
>>>>> are (or are not) part of the URN itself.
>>>> I agree that the proponents of changing the URN syntax need to
>>>> describe how a URN or URI processor (or pre-processor?) would
>>>> behave when encountering what looks like a URN with a query
>>>> component or a fragment identifier component.
>>>> 
>>>> However, there are implications here for registration
>>>> procedures, as well (3406bis). Currently, someone who registers
>>>> a namespace identifier (NID) doesn't need to say anything about
>>>> query components or fragment identifier components within that
>>>> namesapce.
>>> That's ok, because the NSS prohibited by RFC 2141 syntax rules
>>> from containing either '#' or '?'  without their being
>>> percent-encoded. And if they're percent-encoded, the meaning of
>>> them is opaque to the client.
>> 
>> Are you suggesting that the maintainers of a namespace could
>> include the query string or fragment ID in the NSS for URNs in that
>> namespace, with "?" or "#" percent encoded? I'd be curious to hear
>> what the proponents of query strings and fragment identifiers would
>> say about. Given that it doesn't change the syntax from RFC 2141,
>> I'd find that more palatable.
> 
> If you percent-encode # or ? in a URN NSS, it loses its special
> meaning.  It doesn't denote a fragment id or query string.

Indeed, which is why I was confused by your suggestion.

> Really you shouldn't use percent encoding in URNs except when you're
> mapping some other kind of persistent identifier into URN space.

That seems reasonable.

>>> Also, query strings and fragment IDs are about resource content
>>> and presentation of that content, and it doesn't seem generally
>>> appropriate for a a URN namespace to constrain the content of
>>> resources.   That is, URNs and URN resolution are much more
>>> broadly applicable if URNs are independent of resource content.
>> 
>> Good point.
>> 
>>>> Would that need to change, or would the meaning and handling of
>>>> those components be covered only by the syntax spec? Or would
>>>> they be application specific? Could an organization that
>>>> manages a NID include those components in minted URNs?
>>> No, they're prohibited from doing so (and creating the confusion
>>> that would inevitably result) by the URN syntax.   If we need to
>>> make that clearer, by all means let's do so.
>> 
>> Well, there's the rub: as I understand it, the argument is that we
>> need to change the syntax of URNs to allow query strings and
>> fragment IDs.
> 
> If what people want is to be able to refer to fragments of resources
> identified with URNs or to submit queries to resources named with
> URNs, then I think the answer is to define what it means to append a
> fragment I'd or query string to a URN - it means the fragment id or
> query string are ignored for resolution purposes, but interpret the
> fragment I'd or query string with respect to the resource after
> resolution.  Also, the URN is a persistent identifier but there is no
> assurance of persistence for the combination of a URN with a fragment
> ID or query string.

I fear that the distinction between "a URN" and "a URN with a fragment
ID or query string tacked on" will be lost on most people, and that
folks will refer to all of the following as URNs:

urn:foo:bar
urn:foo:bar?zot
urn:foo:bar#zot

>> So "they're prohibited from doing so by the URN syntax" is true in
>> the RFC 2141 world, but folks want to change the syntax in the
>> 2141bis world.
> 

True of so many things.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 12 Jun 2013 18:52:28 +0000

Von: Peter Saint-Andre [mailto:[email-masked]]
> >>>> On 6/3/13 9:51 PM, Keith Moore wrote:

[...]
> > mapping some other kind of persistent identifier into URN space.

+1

> >>> presentation of that content, and it doesn't seem generally

+1

> >>>> those components be covered only by the syntax spec? Or would they
> >>>> be application specific? Could an organization that manages a NID
> >>>> include those components in minted URNs?
> >> need to change the syntax of URNs to allow query strings and fragment
> >> IDs.
> >
> I fear that the distinction between "a URN" and "a URN with a fragment ID or
> query string tacked on" will be lost on most people, and that folks will refer
> to all of the following as URNs:
> 
> urn:foo:bar
> urn:foo:bar?zot
> urn:foo:bar#zot

Yes, since this is what people are used to. I would refer to all of the following as URLs (or http-URIs):

http://example.com/foo
http://example.com/foo?bar
http://example.com/foo#bar

Why can't we specify in 3406bis that query and fragment are ignored for resolution purposes and that handling of those two are delegated to the resource identified by "that part of the URN that comes before '?' or '#'" (whatever you prefer to call it, could "path component" be a name for it?).
> > Those who don't understand URNs are doomed to reimplement them,

Yes, but what is it that people don't understand about URNs and where can they learn those things?

Lars

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2013 14:56:15 -0400

>           foo://example.com:8042/over/there?name=ferret#nose

RFC 3986 is incorrect in several ways as far as URNs are concerned.     
It's a mistake to try to reconcile the differences between RFC 3986 and 
RFC 2141.

The URN namespace identifier and namespace specific string are not a 
"path".

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jun 2013 15:00:40 -0400

> folks will refer to all of the following as URNs:

You're probably right.   But there's always a gap in understanding 
between people who read the specifications and people who don't read the 
specifications.   It's silly to try to write specifications so that 
people who don't read them will understand them.

Though maybe it makes sense to say that any of the following qualify as 
a URI:

URN
URN + a fragment id
URN + a query string

Keith

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jun 2013 09:15:34 +0200

On 2013-06-12 20:56, Keith Moore wrote:
>>> The way I read RFC 3986 puts me more on Barry's side: Every URN is a
>>> URI and thus the URN syntax adheres to the generic URI syntax.
>> But that doesn't follow.
>>
> RFC 3986 is incorrect in several ways as far as URNs are concerned. It's
> a mistake to try to reconcile the differences between RFC 3986 and RFC
> 2141.
>

It is, per RFC 3986. If you think this is wrong, go ahead and get the 
base spec changed.

In the meantime I would recommend to *be* consistent, even if the term 
is confusing.

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2013 09:18:05 -0400

> It is, per RFC 3986. If you think this is wrong, go ahead and get the 

2141 is the base spec.   We're discussing its possible revision.

> In the meantime I would recommend to *be* consistent, even if the term 

I'm pointing out that 3986 is inconsistent and confusing.   Indeed, 
several people here are falling victim to that confusion, which is why 
we need to fix this in 2141bis.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jun 2013 15:26:05 +0200

> 2141 is the base spec.   We're discussing its possible revision.

RFC 3986 is the base spec for URIs. URNs are URIs. As such, RFC 3986 is 
a base spec we need to be consistent with.

> we need to fix this in 2141bis.

If you think RFC 3986 is inconsistent and confusing then, by all means, 
write a summary and post it to a URI-related mailing list, and/or raise 
an erratum.

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2013 09:33:10 -0400

On 06/13/2013 09:26 AM, Julian Reschke wrote:
>>>> It's
> RFC 3986 is the base spec for URIs. URNs are URIs. As such, RFC 3986 
> is a base spec we need to be consistent with.

3986 is not, and cannot be, a base specification for URIs that existed 
before it existed.   3986 was written after the vast majority of URIs 
were defined, and was an attempt to gloss over their differences and 
make future URIs more consistent with one another.     There was nothing 
wrong with trying to make new URIs more consistent, but 3986's trying to 
kill the unique properties of URNs was inappropriate and extremely harmful.

> If you think RFC 3986 is inconsistent and confusing then, by all 
> means, write a summary and post it to a URI-related mailing list, 
> and/or raise an erratum.

Here's the summary:   3986 is simply incorrect as far as URNs are 
concerned, and should not be believed.  Refer instead to 2141.

Producing a 2141bis RFC that set the story straight is a better way to 
fix things than posting an erratum.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jun 2013 15:40:32 +0200

> before it existed.   3986 was written after the vast majority of URIs

It is in my understanding of the term "base specification". It's a full 
internet standard, and obsoletes previous documents on that topic.

> kill the unique properties of URNs was inappropriate and extremely harmful.

Please elaborate on how exactly it is "trying to kill unique properties".

> concerned, and should not be believed.  Refer instead to 2141.

That summary is too terse to be of any use; sorry.

> fix things than posting an erratum.

If a URN is supposed to be a URI, we need to deal with whatever 
discrepancies there are. If it's not, we need to clarify *that* (but I 
have to say that would kill all of my interest in this subject).

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Jun 2013 10:32:40 -0400

On 06/13/2013 09:40 AM, Julian Reschke wrote:
> It is in my understanding of the term "base specification". It's a 
> full internet standard, and obsoletes previous documents on that topic.

But 2141 was and still is the specific definition of URNs.   The 
specific definition is more likely to be correct than a document that 
was written later, which was more broadly scoped, and which tries to 
gloss over differences between several existing types of URI.

Aside: I've said for about 15 years now that it's a mistake to try to 
document existing practice and document recommended practice in the same 
RFC.  3986 is a very good example of that kind of mistake.    The reason 
it's a mistake is twofold:  First, unless they're narrowly focused on 
describing existing practice, RFC authors (being engineers) can't resist 
the temptation to try to fix things, and when they do so they're no 
longer describing existing practice.  Second, mixing existing practice 
and recommended practice in the same document is often confusing to 
readers, especially when the document has a label (like Informational or 
Standard) that is taken to apply to the whole document.

> Please elaborate on how exactly it is "trying to kill unique properties".

The fundamental idea of a URN: label is that it's useful to advertise in 
the name, that the name has a persistent binding with the resource that 
it names.  For example, it makes it possible for a browser or other 
client to attempt to resolve the name in a manner that is suitable for 
names with such persistence, (i.e. URN resolution), and perhaps without 
having specific knowledge of the particular namespace.   The presence of 
the URN: label also advertises that property to document authors needing 
to refer to another document, who can choose (or not) to prefer a URN 
over another kind of URI when a stable reference is desired.

3986 is essentially saying that there's nothing unique about a URN; any 
URI can have that property.   That's really not true, or it's true only 
in such narrow and unusual cases as to be meaningless. Any URL that 
contains a DNS name can't guarantee persistence because there's nothing 
to keep that DNS name from being reassigned - and we've seen this happen 
numerous times in the history of the web. In practice, this doesn't just 
make the original URLs defined inaccessible, it actually has the effect 
of changing the meanings of some of those URLs.

Now if you try really hard you approximate persistent URLs.  You can, 
for instance, pick DNS names that nobody else is likely to want, so that 
there will be no disputes over them.    You can create a new DNS name 
every day that reflects the date that URLs based on that DNS name were 
minted.   You can set up an endowment for your DNS zone that will 
provide money to renew its registration in perpetuity, and provide a war 
chest for the legal defense of that name should someone challenge it on 
trademark or other grounds. You can build HTTP servers that always 
return redirects (and are designed to be efficient at doing so), and 
build interfaces for resource owners to allow them to change those 
redirects as the resources are updated or move to other locations.   
There's nothing wrong with trying to do these things, and they have the 
advantage of working with existing clients.

But for better or worse, the URN approach was, and is, a different 
approach.  3986's efforts to confuse the two was a disservice to everybody.

> That summary is too terse to be of any use; sorry.

The whole point of a summary is to be terse.

Now I recognize that there's a tendency for people to disbelieve 
something that is stated so succinctly.  I could, I suppose, write up an 
Internet-Draft with the title "RFC 3986 is incorrect about URNs" (or 
maybe something less provocative, but you get the idea), include all of 
the required boilerplate and document sections (Security Considerations 
would be interesting), and ask for it to be published as an RFC.   
Either or both of two results seem likely. One result is that the IESG 
would refer discussion of this I-D right back to this working group.  
The other likely result is that said I-D would generate a firestorm of 
controversy that would move discussion of URNs outside of this working 
group, attracting input from a large number of parties with no 
investment into and little understanding of the issues, and making it 
even harder for this working group to conduct its business.

> have to say that would kill all of my interest in this subject).

I think it's more useful to say that a URN is a kind of URI than to say 
that it isn't a kind of URI.    Clearly we intended for URNs to be 
usable in some of the contexts in which URLs were usable, we need a name 
for those contexts, and URI is as good a name as any.

And we do of course need to deal with the discrepancies in 2141bis.   
I'm just describing the nature of those discrepancies.

Keith

---

From: SM <[email-masked]>
Date: Thu, 13 Jun 2013 15:00:58 -0700

Hi Keith,
At 07:32 13-06-2013, Keith Moore wrote:
>something that is stated so succinctly.  I could, I suppose, write 
>up an Internet-Draft with the title "RFC 3986 is incorrect about 
>URNs" (or maybe something less provocative, but you get the idea), 
>include all of the required boilerplate and document sections 
>(Security Considerations would be interesting), and ask for it to be 
>published as an RFC.
>Either or both of two results seem likely. One result is that the 
>IESG would refer discussion of this I-D right back to this working group.
>The other likely result is that said I-D would generate a firestorm 
>of controversy that would move discussion of URNs outside of this 
>working group, attracting input from a large number of parties with 
>no investment into and little understanding of the issues, and 
>making it even harder for this working group to conduct its business.

You have been watching too many IETF movies. :-)  As mentioned above 
the I-D would have to be discussed in here.  It's unlikely that the 
positions would change.

Regards,
-sm