Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 Sep 2013 21:04:06 -0600

On 8/30/13 7:45 AM, John C Klensin wrote:
> 
> 
> --On Friday, August 30, 2013 15:58 +0300 Juha Hakala
> <[email-masked]> wrote:
> 
>> If we have a valid case for using query to provide guidance to
>> the browser or other user agent, or if we think that such
>> cases may arise in the future, we may add a parameter into the
>> query which indicates that the service request and parameters
>> related to it (if any) should be met by the user agent and
>> that the URN resolver may just ignore the query.
>>
>> For instance, something like
>>
>> URN:ISBN:978-952-60-5254-0?agent=user&search=someword
>>
>> would do, assuming that the user agent knows what to do with
>> it. But my gut feeling is that there is a lot to do to define
>> just the URN resolution services and their parameters. If we
>> start listing also user agent resolution service
>> functionality, we'll have plenty of additional stuff to deal
>> with. An easy way to solve this is to reserve agent=user for
>> user agent related services (default being agent=resolver) and
>> leave the specification of these services to the future
>> implementers.
> 
> This seems to me to be a good idea.  It preserves the ability to
> expand things in the future in directions we can only vaguely
> anticipate today (and that some of us find controversial at
> best) without committing ourselves to those extensions in the
> future or requiring that the details be sorted out now.
> 
> Would it be appropriate to incorporate text into 2141bis and/or
> 3406bis that explicitly reserves "agent" as a query keyword and
> specifies "agent=resolver" as the default case?

Personally I'd prefer to avoid reserving key-value pairs for the query
component...

Peter

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Sep 2013 23:21:50 -0400

--On Tuesday, September 03, 2013 21:04 -0600 Peter Saint-Andre
<[email-masked]> wrote:

>> Would it be appropriate to incorporate text into 2141bis
>> and/or 3406bis that explicitly reserves "agent" as a query
>> keyword and specifies "agent=resolver" as the default case?
> 
> Personally I'd prefer to avoid reserving key-value pairs for
> the query component...

Personally, I would too.  Personally, I'd prefer that URIs were
better defined and that some of the underlying issues identified
in Juha's comments were a part of the basic structure so that
tricks with key-value pairs were unnecessary.  I would also like
all URN types to be registered and for all of their designers,
registries and assigners of identifying strings, and resolver
system operators to have the same understanding of "persistence"
and "permanence".   I'd also like a pony :-)

Since I'm unlikely to get any of the things on that list, the
idea of a single reserved key-value pair seemed like a
reasonable suggestion.

    john

---

From: Keith Moore <[email-masked]>
Date: Wed, 04 Sep 2013 10:45:11 -0400

> idea of a single reserved key-value pair seemed like a

I think it would be really odd to define a syntax such that either all
of the query components were passed to the resolution service, or all of
the query components were passed to the resource.

More generally, I am struggling to think of any situation where
overloading of the same protocol element for use for different purposes
by multiple layers has ever been found to be a good idea in the long
term.   Even the use of IP addresses (from the network layer) to form
part of the connection identifier in TCP (the transport layer) is
consistently criticized today as being poor design.   Why would use of
the same query syntax for both resolution services and resources be any
better?

Keith

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Sep 2013 18:16:22 -0400

--On Wednesday, September 04, 2013 10:45 -0400 Keith Moore
<[email-masked]> wrote:

>> Personally, I would too.  Personally, I'd prefer that URIs
>> were better defined and that some of the underlying issues
>> identified in Juha's comments were a part of the basic
>> structure so that tricks with key-value pairs were
>> unnecessary.  I would also like all URN types to be
>> registered and for all of their designers, registries and
>> assigners of identifying strings, and resolver system
>> operators to have the same understanding of "persistence" and
>> "permanence".   I'd also like a pony :-)
>> 
> I think it would be really odd to define a syntax such that
> either all of the query components were passed to the
> resolution service, or all of the query components were passed
> to the resource.

I'm not sure I understand because I think that is what happens
all the time with other URIs.  If nothing else, I don't know
what the model is that parses and distributes different query
components.

> overloading of the same protocol element for use for different
> purposes by multiple layers has ever been found to be a good
> idea in the long term. 
>...
>  Why would use of the same query syntax
> for both resolution services and resources be any better?

100% agree.  I think the general approach is a bad idea in
principle.  But I also think that convincing arguments have been
made as to why the different services may need to be involved at
different points and the alternative to this little trick (or
something like it) would be fork URNs away from the RFC 3986
generic URI syntax.  As I've said before, in a different world,
that would have a lot of appeal to me.  But, in this world, that
is probably an even worse idea.

    john

---

From: Juha Hakala <[email-masked]>
Date: Thu, 19 Sep 2013 08:21:58 +0300

Hello,

>> Personally I'd prefer to avoid reserving key-value pairs for
It might be better to keep 2141bis simple and leave any guidelines of 
how to use query out of it. Then there will be no need to amend or 
expand the text in the future as regards the query utilization.

The future version of rfc2483 will not even try to provide an exhaustive 
list of resolution services, since no such thing can exist. Instead 
there will be an (IANA) registry of services. This registry should 
contain a mnemonic (for example I2R for URI to resource) for each 
service and query syntax for requesting them from resolvers (for example 
"?s=I2R"). In addition, the registry has to list service-specific 
parameters.

Instead of supplying the query related information piece by piece in 
2141bis, 3406bis, 2483bis and in the (proposed) registry of services it 
is better to collect it into one place from which the implementers can 
easily find it and where it is as easy as possible to maintain it.

I am not sure if we need to / can tell the implementers what kind of 
query combinations make sense. Making such a document exhaustive would 
be difficult.

IMO it would not do any harm to reserve agent as a query keyword.

Juha

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678

---

From: John C Klensin <[email-masked]>
Date: Thu, 19 Sep 2013 11:10:09 -0400

Hi.   This note started as part of a reply to 

To be clear, I've got two personal goals in this.  I hope most
of the WG shares them, but I have no way to tell.  

One is to get the core set of URN specs far enough along that
the WG can finish them and get them through the process and
published.  Because of necessary interdependencies, I think that
list is 2141bis (syntax), 3406bis (namespace definition and
registration), last month's ns-reg-transition document, and,
probably, 3188bis (NBN).   I'm concerned that, if we don't get
on with this, various parties will make assumptions about what
we will do or should do and go off on their own, leading to
future compatibility and interoperability problems.  In
addition, there are a number of URN registrations in various
pending states now (including one that stirred up a lot of noise
on the IETF list in the last weeks).  We would be far better off
if they could get approved/registered under 3188bis.  Otherwise,
we will need to worry about whether or not they need to be
upgraded.  

The WG will be three years old in late November.  I hope and
wish we could set a target of having the documents in the hands
of the IESG well before that, ideally before Vancouver.   

Second, it seems obvious to me that we need to future-proof
2141bis and, to the extent necessary, 3406bis.  There have been
several incidents around the IETF in recent years in which
people have said things equivalent to "cannot change or expand
that feature because it was specified a different way once and
has to be that way forever".  The discussions that follow are
always complex and unpleasant because the tradeoffs between
stability and increased functionality or interoperability are
difficult; usually the results are "least bad" solutions.  

In particular for queries, 2141 was wise in reserving "?" and
therefore queries, but, if we even allow "?" in the syntax, we
need to be careful that we don't create a future trap for
ourselves.   A registry of query keywords would be a big step
and almost certainly not in the spirit of 3986.  It is pretty
clear to me that, if we want to do it, we need to do it now, not
just to create the registry and rules for it but probably to
define a way of distinguishing, by syntax, between keywords that
are intended to have global meaning and those that are to be
interpreted locally.  I don't see reserving a specific keyword
or two to have nearly the same implications as trying to give
still-unspecified keywords global meanings but either approach
becomes part of the critical path and interferes with my "swift
completion" fantasies, especially given the speed at which this
WG seems to hold discussions.

best,
   john

p.s. the supposed WG LC that started this thread was announced
for two weeks starting 13 August and was supposed to terminate
on 27 August
(http://www.ietf.org/mail-archive/web/urn/current/msg02062.html).
It is now over three weeks since the closing date and I, at
least, have no idea where we are.  Do the WG Chair(s) think we
have consensus?  Is a new version of 2141bis to reflect the many
comments expected and, if so, when?  Given the dependencies
between 2141bis and 3406bis and the risk that details of the
latter will require changes to the former, when do we expect the
promised new version of 3406bis?

---

From: John C Klensin <[email-masked]>
Date: Fri, 20 Sep 2013 02:27:15 -0400

> It might be better to keep 2141bis simple and leave any
> guidelines of how to use query out of it. Then there will be
> no need to amend or expand the text in the future as regards
> the query utilization.

The problem I see is that, unless we leave "?" as "reserved, use
prohibited" --which would not serve any of the needs that have
been identified for queries-- we either need to specify
guidelines now or lose control of it.  Global (i.e., across
namespaces) keywords, any reserved keywords, any attempt to
distinguish between queries to resolution mechanisms and queries
to objects, and so on either need to have provision made for
them now or we will find that adding them later is hopeless.
 
> The future version of rfc2483 will not even try to provide an
> exhaustive list of resolution services, since no such thing
> can exist. Instead there will be an (IANA) registry of
> services. This registry should contain a mnemonic (for example
> I2R for URI to resource) for each service and query syntax for
> requesting them from resolvers (for example "?s=I2R"). In
> addition, the registry has to list service-specific parameters.

I'm not sure.  We've got IANA registries for URN namespaces
(http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml).
They could easily be extended to include per-namespace
resolution services information and parameters if that were
really needed.  Do you think a separate mechanism is important?

> Instead of supplying the query related information piece by
> piece in 2141bis, 3406bis, 2483bis and in the (proposed)
> registry of services it is better to collect it into one place
> from which the implementers can easily find it and where it is
> as easy as possible to maintain it.

Historically, most "query related information" has been
per-domain (or, in our case, presumably per-NID) and not in any
sense global.  In particular, there has never been a
requirement, s.t., e.g., given
  http://www.example.com/?fribble=zorg
and 
  http://www.example.net/?fribble=zorg
that either "fribble" or "zorg" have the same interpretation in
both URLs (or even that "zorg" does if "fribble" happens to do
so).

So were are fairly far into uncharted territory here.  And,
fwiw, I think it is certain that there will be at least some
query keywords that the relevant namespace maintainers will have
no desire to give a global interpretation.  That is likely to be
another example of "if we tell then to not do it, they will
ignore us".

> I am not sure if we need to / can tell the implementers what
> kind of query combinations make sense. Making such a document
> exhaustive would be difficult.

or impossible.
 
> IMO it would not do any harm to reserve agent as a query

yes, although that is, to some degree, part of the problem (see
the other note).

best,
    john

---

From: SM <[email-masked]>
Date: Sat, 21 Sep 2013 10:28:04 -0700

Hi Andrew, Alfred,
>of the IESG well before that, ideally before Vancouver.

The milestone was February 2013.

>promised new version of 3406bis?

I have not seen any response to the above questions.  I think that it 
would help the WG work if the WG Chairs could provide a timely response.

Regards,
-sm

---

From: Juha Hakala <[email-masked]>
Date: Mon, 23 Sep 2013 08:03:44 +0300

Hello,

> them now or we will find that adding them later is hopeless.

We need to specify guidelines for using query, but we do not need to do 
that in 2141bis or 3406bis. Resolution services and their properties are 
dependent on the underlying technical infrastructure and therefore 
subject to change. RFC 2483 was a good start, but we know now that new 
services pop up constantly, and at least in some cases existing services 
are enriched; I2C is a good example of that.

> really needed.  Do you think a separate mechanism is important?
It would be cumbersome to provide resolution service specifications only 
in the context of namespace registrations. Same information would be 
repeated many times, and it would be difficult to find all services and 
service parameters.

The current registry for URN namespaces can however be extended with 
service-related information. There would first be the list of services 
and service parameters, followed by namespace registrations (which may 
provide information about global / local services available).

As far as I am concerned, we can choose whatever approach IANA prefers - 
new registry or an extension of the current one.
> both URLs (or even that "zorg" does if "fribble" happens to do
There are many popular Internet protocols (for instance, SRU, OAI-PMH 
and OpenURL) which rely on globally coordinated usage of query. These 
standards are used across domains (libraries, publishers, universities 
etc.). As far as I know, there has been no problems in using query as 
required by these protocols. IMO queries in URNs will be simple in 
comparison. See for instance

http://www.openarchives.org/OAI/openarchivesprotocol.html

for relatively complex usage of query (which is more or less globally 
supported by institutional repositories).

With URNs, we have assumed since RFC 2483 that it is possible to specify 
a limited set of generic resolution services. If that is the case, there 
may be per-NID services, but there will also be services which will be 
supported across multiple NIDs. And any per-NID service may later become 
more widely used.

For instance, users want to find copies of resources that they can 
access. Underlying technical infrastructure, based on the OpenURL 
technology, is widely supported by publishers and libraries. Therefore 
multiple URN namespaces have a need and technical capabilities to 
support new service "URI to accessible resource", or I2AR.
>
> So were are fairly far into uncharted territory here.
This territory may be uncharted to IETF, but not to e.g. libraries and 
publishers.
>   And,
It may help to allow specification of formal, informal and experimental 
resolution services and perhaps even service parameters. Nobody else is 
likely to start using an experimental resolution service, but other 
users may be interested in registering an experimental service as 
formal, once it has been battle proven.

All the best,

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 23 Sep 2013 16:29:35 +0900

Hello Juha, John, others,

Caveat: I have been following the urn WG only with a limited time 
budget, but see below for my thinking.

> IMO it would not do any harm to reserve agent as a query keyword.

URNs are resource identifiers. As such, I think that if they have query 
parameters, these should be defined by the resource, without any 
influence by resolution services. That's what I'd assume for any other 
URI scheme, too.

For something close to resolution parameters, I seem to remember that an 
early URI spec defined a place for such parameters after a ';'. I can 
dig up the spec if that helps.

However, I think that it might be better to create a new scheme, or new 
schemes, for resolution services if they need additional parameters. An 
example generic 'resolution service' scheme might look as follows:
urn-resolution:urn=urn:isbn:123-45678-90;resolve-to=meta_data
Schemes for particular resolver protocols are also possible; some of 
them might not need their own scheme, in particular if they run over http.

This has several advantages: It separates the resource from the 
resolution, which is conceptually how things should be.[*] It allows 
both resources and resolution to use whatever 'query' parameters they 
deem appropriate, without name conflicts, and it allows the query 
parameter space for resolution services to be developed from now on, at 
a point where we are not sure yet how much these parameters will be 
shared between resolution services.

Hope this helps,    Martin.

[*] Just to give an example, nobody would propose to put a "proxy" 
parameter into an http: URI, although HTTP proxies can be thought of as 
a kind of resolution service. Also, nobody would propose to add 
something to the http: URI syntax in order to e.g. distinguish a "GET" 
request from a "HEAD" request. But this is quite close to the 
distinction between 'resource' and 'metadata' in the URN resolver 
discussions.

---

From: Andrew Newton <[email-masked]>
Date: Mon, 23 Sep 2013 14:06:42 -0400

On Thu, Sep 19, 2013 at 11:10 AM, John C Klensin <[email-masked]> wrote:
> have consensus?

John,

Thank you for this note. I should have sent a message to the list
earlier regarding the WGLC.

It is my opinion that we do not have consensus on 2141bis with respect
to Keith Moore's observation regarding a difference between the query
parameters used by a resolution service and those used by a resource.

This issue needs to be addressed in some manner, either by a technical
solution, text explaining why it is not of concern, or something in
between. If ideas have already been put forward, then we need to call
them out specifically in separate email threads as the discussions on
this list can be quite involved.

I hope this helps. If there are any questions, please ask.

-andy

---

From: Juha Hakala <[email-masked]>
Date: Tue, 24 Sep 2013 08:33:50 +0300

Hello,

On 23.9.2013 21:06, Andrew Newton wrote:
> between.
I believe this issue is not of concern (from 2141bis and 3406bis point 
of view).

Our technical environment consists of (among other things):

- resolvers, which may deal with 1-n namespaces (and even 1-n persistent 
identifiers)
- resources, such as HTTP servers or institutional repositories, and
- objects and their surrogates, such as e-books and metadata about them

By definition, every URN is always processed by the appropriate URN 
resolver first. Since we do not have a resolver discovery service in 
place, for the time being we use HTTP URIs which include the resolver 
address such as http://urn.fi. There is not much intelligence in current 
resolvers; they often just map the URN to one or 1-n URLs.

In the future, when query is used to convey additional information about 
the users' wishes, resolvers must get a lot smarter. They must be able 
to understand which URN resolution service & parameter is being 
requested. They must also know which resource(s) will be able to supply 
what the human / software user is asking for. In order to simplify the 
implementation process, resolvers will transform the URNs into something 
that can be processed by the resources.  For instance, a user may want 
bibliographic information about the object identified by the URN. If the 
appropriate resource (e.g. an institutional repository) supports SRU 
query protocol, the resolver can create an SRU search request and pass 
it on to DSpace, Fedora or other repository application is used.

If the resolver knows that the resource supports URN queries as such, 
the resolver has an option of passing the URN unchanged to the resource. 
But this may not be the best policy (see below).

HTTP URI http://urn.fi/URN:ISBN:978-952-60-5254-0 is currently resolved 
to URL https://aaltodoc.aalto.fi/handle/123456789/10927.  No other 
resolution services are available.

In the future, a user may ask for a full bibliographic description of 
the book identified by this URN:ISBN. In order to facilitate this, the 
URN resolver at http://urn.fi (which is globally responsible of 
resolving all URN:ISBNs where ISBN starts with 978-952) must know that 
metadata about Finnish books is available in e.g. the national 
bibliography and that this database supports SRU search protocol.

Then the resolver can change for instance URN + query

http://urn.fi/URN:ISBN:978-952-60-5254-0?s=I2C&p=fullRecord

into a search request the SRU server in the national bibliography 
database can deal with (what follows is just an example of what a 
resulting search might look like):

http://linnea1.linneanet.fi:11391/voyager?version=1.1&operation=searchRetrieve&query=978-952-60-5254-0&maximumRecords=1&recordSchema=marcxml

URIs like this are not persistent (and unlike RFC3986 says, they 
certainly do not identify anything ;-)). The mapping tables in the 
resolver have to be maintained so that even if the record schemas, 
protocol versions and applications change, the users will still get what 
they want.

I guess any resource such as database application could be enhanced so 
that it can deal with "raw" URN queries, but for existing (and future) 
standard driven resolution services it is more economical to let the 
resolvers convert the URNs centrally into e.g. SRU queries, OpenURLs 
etc, since these URIs are already widely supported by a large number of 
different Internet resources. Allowing queries to pass unchecked and 
unprocessed through URN resolvers to resources would also increase the 
risk that the resources would not know what to do with the particular 
query. A resource may support only a subset of resolution services and 
service parameters, and maintaining all this detailed information in the 
URN resolver would be cumbersome.

Many current and future resolution services will be based on widely used 
standard protocols such as OpenURL and SRU. This will make it easier to 
get started with query usage and make the existing resolvers smarter. No 
doubt there will also be localized and / or non-standard services, and 
for them passing the URN + query on unchanged from the URN resolver to 
the resource may be a practical alternative.

All the best,

Juha

> If ideas have already been put forward, then we need to call
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  Juha Hakala
  Senior advisor

---

From: "Svensson, Lars" <[email-masked]>
Date: Tue, 24 Sep 2013 08:12:40 +0000

On Montag, 23. September 2013 20:07, Andrew Newton wrote:

> It is my opinion that we do not have consensus on 2141bis with respect to
> Keith Moore's observation regarding a difference between the query

In my opinion we also do not have consensus on the allowed/reserved characters, particularly ~, / and &.

Best regards,

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: "Martin J. Dürst" <[email-masked]>
Date: Thu, 26 Sep 2013 10:55:02 +0900

Hello Juha, others,

> - objects and their surrogates, such as e-books and metadata about them

Can we *please* use a terminology that isn't in conflict with the 
terminology of RFC 3986 (URI spec)?

The term 'resource' is used in RFC 3986 (and many other places) for the 
stuff that is denoted by URIs (including URNs). So please change 
'resource' to something like 'server infrastructure' or so, to avoid 
confusion.

> resolver first.

Not necessarily. There may be URN namespaces such as one for integers 
(surely something very persistent; I seem to remember there having been 
a proposal for such a thing, but I don't remember how far it went), and 
resolution for them may be just built in to some of the software that 
uses them. Of course you could also call this built-in software 
component a resolver, but then you'd also have to call the 
software/protocol/server combination that deals with http requests a 
resolver.

> Since we do not have a resolver discovery service in
> certainly do not identify anything ;-)).

Of course they identify something. They identify the search request, or 
the results of that request, if nothing else.

> The mapping tables in the

I would like to point out that in the examples above, there is no 
example of an URN with a query part. In both the http://urn.fi/ example 
and the http://linnea1.linneanet.fi example, the query part is a http 
query part.

Can you please make an example with query parts directly on an urn, and 
show how it fits into the above picture?

Regards,   Martin.

---

From: Juha Hakala <[email-masked]>
Date: Thu, 26 Sep 2013 09:03:08 +0300

Hello,

It seems that we need to clarify the terminology we use a bit.

On 26.9.2013 4:55, "Martin J. Dürst" wrote:
> The term 'resource' is used in RFC 3986 (and many other places) for 
> the stuff that is denoted by URIs (including URNs). So please change 

I was confused myself by for instance this statement by Keith which is 
pure 3986:
> Given that there is today a huge number of network-accessible resources
> that accept queries and process them, why is your assumption that this
> won't be a common scenario for resources named by URNs?

but then, once I had grasped that there could be two different meanings 
of resource here, tried to clarify that in my response.

The problem I see is that resource as used in RFC 3986 can be a database 
(which may accept a request and process it) or an object (such a single 
record within that database) which has been identified by URN. Of course 
the URN resolvers are, in RFC 3986 terminology, resources as well. So if 
we stick to the RFC 3986 terminology URN is resolved by resource, and as 
a result 1-n URIs are processed by 1-n resources, and in the end we get 
the identified resource or its surrogate. Instead, like Martin suggests, 
we should be more precise and talk about URN resolvers, Internet servers 
(to which the URIs generated in the resolution process are passed) and 
identified resources (and their surrogates which may be identified 
resources as well).
> (surely something very persistent; I seem to remember there having 
> been a proposal for such a thing, but I don't remember how far it 
> went), and resolution for them may be just built in to some of the 
> software that uses them. Of course you could also call this built-in 
> software component a resolver, but then you'd also have to call the 

I look forward to seeing the first such namespace in real life.

> Of course they identify something. They identify the search request, 
> or the results of that request, if nothing else.

I disagree, because I have a librarian's formal approach to what 
"identify" means. You can of course say that the URI above identifies 
the retrieved bibliographic record. But any change in the underlying 
technology will change this "identifier". An analogy from the real 
world: that you can claim that somebody's email address or snail mail 
address identifies him/her, but such identification is known to be 
non-persistent and unreliable (many people can live in the same 
addresss; same person can have many email addresses) and therefore it is 
not used. And libraries do not use URLs such as the one above but URNs 
to identify bibliographic records in their databases.

I don't mind what W3C or IETF in general says about identification, but 
in this WG identification should be something reliable and identifiers 
unique and persistent, because that's what URNs are supposed to be.
> example of an URN with a query part. In both the http://urn.fi/ 
> example and the http://linnea1.linneanet.fi example, the query part is 
> a http query part.
>
> Can you please make an example with query parts directly on an urn, 
> and show how it fits into the above picture?

Sorry, I do not understand this. Unless I am mistaken the URN part is no 
different from the generic URI syntax query. We may/shall specify syntax 
(reserved keywords etc) for URN queries which will be understood by 
resolvers, but  at least so far we have not made any deviations from the 
syntax specified in RFC 3986.

Best regards,

Juha

-- 

  Juha Hakala
  Senior advisor