[urn] query component in URNs

[Peter Saint-Andre <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the interest of moving forward with rfc2141bis and with my document
editor hat on, I've been reviewing list discussions and earlier
document versions so that we can be clear about open issues.

Because the fragment identifier issue is quite large and has received
a lot of discussion, I've decided to focus first on the issue of query
components in URNs.

Juha Hakala mentioned the topic in late 2010:

https://www.ietf.org/mail-archive/web/urn/current/msg01485.html

"From the PersID point of view, both <query> and <fragment> are
vitally important. We support the idea of reserving <query> for the
transfer of service parameters as a part of the resolution process."

In March 2011, Juha again mentioned query components:

https://www.ietf.org/mail-archive/web/urn/current/msg01507.html

"As regards the URN syntax, the key issue - at least from my point of
view - that should be discussed more widely is the usage of <fragment>
and <query> in the way suggested in RFC2141bis. The reason why it is
vital to make firm decisions concerning these features is that there
are projects that intend to use both of them, and must have explicit
permission and guidelines for doing that."

Martin Duerst pointed out that nothing is really stopping us from
allowing query components:

https://www.ietf.org/mail-archive/web/urn/current/msg01510.html

"That's quite different from the query part; if the urn spec wants to
allow a "?" and some following stuff, it can do so, and it can put on
the syntactic restrictions (as long as they are within the bounds of
the URI spec) and semantic restrictions the WG deems appropriate."

Although I don't claim to fully understand the proposed use of query
components in URNs, it appears to be something that could be supported
in, say, an HTTP-based resolution service. Thus a URN of
urn:isbn:978-951-1-25645-8 could be resolved over HTTP:

http://resolver.example.com/urn:isbn:978-951-1-25645-8?param=value

However, that would not necessitate adding query components to URNs
themselves. This appears to be consistent with something that Juha
sent in August of 2011:

https://www.ietf.org/mail-archive/web/urn/current/msg01574.html

"The reason why URN:ISBN namespace does not allow fragments has to do
with ISBN syntax. This is OK:

http://urn.fi/URN:ISBN:978-952-10-7060-0

but I am not allowed to add anything to the namespace specific string
even if the media type in which this book is published would allow
that. Of course, adding <query> would be OK since it would not be part
of the identifier. "

And:

https://www.ietf.org/mail-archive/web/urn/current/msg01582.html

"According to the RFC2141bis, fragment ID - if we allow its use in the
URN syntax - will be part of the identifier. An identifier which
consists of and ISBN and a fragment no longer identifies the book as a
whole but a component part of it. Whereas ISBN with <query> still
identifies the book as a whole; the role of the <query> is to specify
the resolution service the user wants."

The issue arose again in December of 2011:

https://www.ietf.org/mail-archive/web/urn/current/msg01665.html

"No, I was just emphasizing the point that if we piggyback service
parameters in <query> they will not be part of the URN itself.
Whenever there are fundamental changes in technology, the URN itself
remains the same, but the service parameters may be encoded differently."

Confusingly (at least to me), in March of 2012 Juha made the following
statement:

https://www.ietf.org/mail-archive/web/urn/current/msg01735.html

"As an aside, rfc3187bis is still out of date in the sense that it
assumes (erroneously) that the <fragment> is part of the NSS. If this
were so, you could not use <fragment> in the ISBN namespace since the
ISBN standard does not allow the users to add anything to the ISBN
string. But a construct where ISBN forms the NSS and <fragment> and
<query> may be added to it, gives us free hands. I shall revise the
I-D in this respect in the near future. Such revision requires also
discussions with the International ISBN Agency, since via <fragment>
usage URN:ISBN gains functionality which is not available in the ISBN
itself. "

Notwithstanding that statement, Section 2.3 of
draft-ietf-urnbis-rfc2141bis-urn-03 contained the following text:

   The <query> part MUST NOT be present in any *assigned* URN.  A
   <query> part can only be added to an assigned URN and appear in a URI
   *reference* [RFC3986] to a URN that is intended to be used with URN
   resolution services, and, in the spirit of the general specification
   of this part in RFC 3986, its purpose is restricted to indicate the
   requested URN resolution service and particular service aspects of
   the intended resolution response, e.g., the kind of metadata or
   content sought that are bound to a given object identified by the
   basic, assigned URN.

I draw two conclusions:

1. A query component would not be needed to provide a persistent,
location-independent identifer for, say, an ISBN resource like
978-951-1-25645-8.

2. Aside from a possibly ambiguous statement from Juha, no one has
proposed that we modify the URN syntax to allow query components in URNs.

Unless someone objects, I shall consider this issue closed.

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJadKAAoJEOoGpJErxa2pbC0P/A5QqNb365I5oz+gskNLr0dV
5vq4zBawxgRDUG8jf67l4ZuMeF6aMXOpSlHoJN3VbXt6nfwPgW4w221MSVJM0Dna
4rT9xviSZEjEPxpjkIPrwskSesfTkBcC/C1uH1pGnyLOcC1c0xerBUCyo3vcQUAB
de4+iC1JNhQjF7jGCC4WP2jPfpk9AvP70mZrcvd1bNmMJmdgczONIAT5PaAj0xQO
WK5glcKwCNvB34IrGU/WJuJpaJJ8yYBSd5OFH76D/cI27yf/I+v5sZANQDfXFMpI
rb1yZMDWk1xvuawUgshP0dyCVdGDcSmIQnNOLURbHMDqXqidC5rstid87vdpq+O+
zlW3ubvLYJjhIBhTLqiD6LpuImzxzJMtx0/r5Tb1f2D2iuDIZ0boO/7+gfXH7pZ3
pj2CjWc+DPNOz075kDUxoCJ4QUyMA6kNenvcCh5bkW1FIypu95sMic8NeqWJs/KE
wyLbQxYjkNwO0EyiC2M6ItmqmxHFrWXaAVGzyMrLeNAQIyqpi7moBZJtfTrPQAGe
7K08txf/W232IIqJ6M67g2vuLgmAg4X7oIj5JxQAmnluOOvDYJyRa2tpl+zxWxIh
Tdx2ImQFZkAsgseL0dcAUtvOmTryIHdQ2mnHGdelDoRgxe/5FyoJ8e+4IjFfThKF
r5NtgfCu+AqRQyuO2O8z
=43Sg
-----END PGP SIGNATURE-----