Subject: [urn] Query choices

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 21 Jul 2014 18:55:23 +0900

I tried to answer some of the previous mails, but concluded that the 
following may be easier and faster.

I'm trying to list some of the choices that are possible for the 
upcoming URN spec with respect to query. The ones below are the main 
ones I have found.

A) (continue to) not allow query

B) (continue to) not allow query but provide (a) separate scheme(s) for 
using URNs with queries

C) allow each Namespace to opt in to use queries, and define how they 
are used (syntax details, semantics, within some common boundaries)

D) define a common use for query parts for URNs; allow each Namespace to 
opt in to this common use

E) define a common use for query parts for URNs; do not require opt-in 
so that this use is possible with any Namespace when desired/appropriate

My understanding from fairly recent email is that John is somewhere 
around C), Yuha probably close to E), and Larry around B). Of course I 
might have read something wrongly; in that case I apologize in advance.

My personal preference coincides with Larry (B), but probably isn't as 
sharp as his. I'd be okay with C) if that's what the WG decides to do 
(after all, it's mostly the people who define and use certain Namespaces 
who have to live with the queries on them), and could live with D) or E) 
if that makes the WG and the IETF happy because I'm not using URNs.

I'd also like to note that none of the above alternatives would need a 
separation of URNs from RFC 3986. RFC 3986 delegates the question of 
whether and what queries are allowed to each scheme, in our case urn:.
Also, there is nothing in RFC 3986 (or in RFC 4395, which is relevant 
for registration) that says that the syntax of a scheme cannot be changed.

Regards,   Martin.

---

From: Andrew Newton <[email-masked]>
Date: Mon, 21 Jul 2014 09:45:58 -0400

On Mon, Jul 21, 2014 at 5:55 AM, "Martin J. Dürst"
<[email-masked]> wrote:
> separation of URNs from RFC 3986. RFC 3986 delegates the question of whether
> and what queries are allowed to each scheme, in our case urn:.
> Also, there is nothing in RFC 3986 (or in RFC 4395, which is relevant for
> registration) that says that the syntax of a scheme cannot be changed.

Not to disagree with you, but people have pointed out to me the figure
at the end of Section 3 (http://tools.ietf.org/html/rfc3986#section-3)
which they have interpreted as RFC 3986 disallowing queries and
fragments in URNs.

-andy

---

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 21 Jul 2014 14:03:25 +0000

Martin,

> around C), Yuha probably close to E), and Larry around B). Of course I

s/Y/J/

> if that makes the WG and the IETF happy because I'm not using URNs.

Thanks for providing this list. My preference is C).

> for registration) that says that the syntax of a scheme cannot be changed.

Best,

Lars

---

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 21 Jul 2014 14:07:58 +0000

Sorry, sent too quickly...

> Thanks for providing this list. My preference is C).

That said, I still think that *if* the scope of sending parameters with a urn (using the URI query syntax) is to give information to resolution services what to do with the URN, then the use of queries should be handled in 2483bis and not in 2141bis. This would also solve the question if the query is "part of the urn" or not.

Lars

---

From: Julian Reschke <[email-masked]>
Date: Mon, 21 Jul 2014 16:31:33 +0200

> which they have interpreted as RFC 3986 disallowing queries and

Well, that's a misreading of the spec. It's just an example of two URIs 
and how they are decomposed.

Best regards, Julian

---

From: Larry Masinter <[email-masked]>
Date: Tue, 22 Jul 2014 02:43:36 +0000

Thanks Martin, this is helpful.

> A) (continue to) not allow query
OK with me, but includes B.

> B) (continue to) not allow query but provide (a) separate scheme(s) for using
> URNs with queries

One way to accomplish most of (E)

> C) allow each Namespace to opt in to use queries, and define how they are
> used (syntax details, semantics, within some common boundaries)

This is fine with me, but changing an existing Namespace should be done
 with caution for backward compatibility

> opt in to this common use

This is (C), but with "common boundaries" taken to an extreme

> E) define a common use for query parts for URNs; do not require opt-in so
> that this use is possible with any Namespace when desired/appropriate

This is (D) if "desired/appropriate" is treated as "opt-in".

> might have read something wrongly; in that case I apologize in advance.

I prefer B or C. If the features of E are really needed, use B instead.

> who have to live with the queries on them), 

Just be careful that the users exceed the definers for existing
Namespaces.

> and could live with D) or E)

If we don't care about users because we're not users, I have
to confess: I don't use URNs either.

> for registration) that says that the syntax of a scheme cannot be changed.

RFC 2141 URN Syntax is standards track, so the bar for updating 
should follow the rules for updating standards track document:
based on implementation experience. If there is implementation
experience with using ? in URNs, which would justify C, D, or E,
please cite it. If there is none, stick with B.

Larry
--
http://larry.masinter.net

---

From: Michael Mealling <[email-masked]>
Date: Tue, 22 Jul 2014 01:28:46 -0400

De-lurking:

I try not to get sucked into this discussion these days but since I've dealt with many uses of URNs in the course of developing software (from registered uses in XMPP to numerous unregistered uses inside various well known systems) and I helped authors write several URN registration documents I think I understand some of their motivations. 

Based on that and my rather rusty memory of the old discussions I still think I would opt for D. I remember discussions with TimBL back in '92 (prior to the revisionist history suggesting Tim had an actual design behind URLs) saying that query parameters and fragments were 'modifiers' of the base 'URL'. In practice query parameters were simply alternative representations of a path. Fragments really were orthogonal to the URI since they were interpreted within the scope of the returned MIME type. 

I've been writing REST-ful APIs using Node lately and there is no functional difference between /v1/foo/:id and /v1/foo?id=:id. Query parameters are a hold over from a world that doesn't exist anymore. So I'm loath to perpetuate the fiction that query parameters are somehow 'special'. 

For me the distinction between D and E is one of whether Joe Random Developer out there even gives a crap. I've seen perfectly reasonable people attempt to do this: mailto:[email-masked]#fragment expecting to be able to denote a part of an email. Or something. I'm not sure they even understand what the mailto URI scheme means. So you can't really stop them. The only thing that stops them is a meaningless result.

So while I can't stop someone from doing this: urn:uuid:01489A2A-6F30-4BF8-A9E2-CC9D47D5E661#cthulurises I'm fairly sure they won't do it outside some closed system simply because a) there is not resolution system for UUID URNs and b) if there were it would be nearly meaningless to attach a fragment to it.

So go for D. Make sure that if someone decides to allow them for a namespace that they follow the existing query parameter standard. But I would strongly encourage ALL URN namespaces to disallow their use since in practice they merely represent an extension of the name, not some external resolution API parameter expression mechanism.

For those that remember the discussions in '93 there was a proposal that query parameters and fragments be put into separate attributes to the HTML anchor tag. Have fun thinking about the ramifications of that. ;-)

So yea, I'm behind D.

-MM

Michael Mealling
+1-678-640-6884	@mmealling
Schedule a meeting:  http://meetme.so/michaelmealling

On Jul 21, 2014, at 5:55 AM, Martin J. Dürst <[email-masked]> wrote:

> I tried to answer some of the previous mails, but concluded that the following may be easier and faster.
> 
> I'm trying to list some of the choices that are possible for the upcoming URN spec with respect to query. The ones below are the main ones I have found.
> 
> B) (continue to) not allow query but provide (a) separate scheme(s) for using URNs with queries
> 
> C) allow each Namespace to opt in to use queries, and define how they are used (syntax details, semantics, within some common boundaries)
> 
> D) define a common use for query parts for URNs; allow each Namespace to opt in to this common use
> 
> E) define a common use for query parts for URNs; do not require opt-in so that this use is possible with any Namespace when desired/appropriate
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 22 Jul 2014 18:35:21 +0900

Hello Andrew,

> which they have interpreted as RFC 3986 disallowing queries and

Seems that a lot of squashing of misunderstandings is needed, but I'm 
glad to help. This seems (*) to refer to:

    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

Now the text here says "two *example* URIs". One of the *examples* is 
"urn:example:animal:ferret:nose". That example very clearly doesn't have 
a query part. Other examples such as
"foo://example.com:8042/over/there#nose" and
"foo://example.com:8042/over/there" would also not have query parts. It 
would therefore have been very wrong if the figure would have shown it 
as having a query part.

Any generalization from this example have to be done within the 
boundaries of logic. It's very clear that if we have an example of an 
URN with a scheme part, then there are URNs (at least the one we just 
saw) with scheme parts. On the other hand, observing an example of a URN 
without a query part cannot lead to the conclusion that no URN can have 
a query part. Such a conclusion would be about as wrong as concluding 
that all primes are even from the fact that 2 is a prime and is even.

Of course, at the time of writing of RFC 3986, there was no other choice 
of URN example for RFC 3986 than an URN without query. This also shows 
that, contrary to claims made earlier on this list, RFC 3986 actually 
was aware of RFC 2141. And even if RFC 2141 gets updated by the work of 
this WG and allows query parts, I think nobody is proposing to disallow 
URNs without query parts, and so the example in RFC 3986 will continue 
to be valid, and no split of URNs from RFC 3986 at all is necessary.

Regards,   Martin.

(*) Strictly speaking, that figure isn't at the end of Section 3, 
because Section 3 ends just where Section 4 begins, which is a few pages 
later. It is at the end of the introductory text of Section 3 that isn't 
part of any subsection of Section 3.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 22 Jul 2014 20:41:15 +0900

Hello Michael,

> De-lurking:

Your historical perspective,... is very much appreciated.

> So go for D. Make sure that if someone decides to allow them for a namespace that they follow the existing query parameter standard. But I would strongly encourage ALL URN namespaces to disallow th…

I'm not sure if I expressed myself clearly about D), or if I'm 

 >> D) define a common use for query parts for URNs; allow each 
Namespace to opt in to this common use

I did't just mean "follow the existing query parameter standard" (which 
I interpret as "what RFC 3986 says" which in turn would roughly boil 
down to "query is everything between the first "?" and the first "#" in 
an URI"). I explicitly meant something along the lines of what Juha 
(sorry for the typo in my previous mail) was proposing, namely that 
across all (opted-in) URN Namespaces, there would be a common set of 
query parameter names with each having a defined set of query parameter 
values.

In contrast to that, I meant C):

 >> C) allow each Namespace to opt in to use queries, and define how 
they are used (syntax details, semantics, within some common boundaries)

in the sense that e.g. the issn: scheme could define some query 
parameters for periodicals (maybe volume and number to indentify issues 
from a periodical, or whatever), the isbn: scheme could define some 
query parameters appropriate for books, and so on, but there wouldn't be 
parameters or values that could be used across schemes unless these 
schemes had been designed/defined in concert.

Regards,   Martin.

> For those that remember the discussions in '93 there was a proposal that query parameters and fragments be put into separate attributes to the HTML anchor tag. Have fun thinking about the ramificat…

P.S.: This is totally unrelated to the discussion at hand and OT for 
this WG, but I'm sometimes worried we'll end up with some of these 
ramifications with Web Intents (http://www.w3.org/TR/web-intents/). I 
hope to be proven wrong.