Subject: Re: [urn] Transition of 2141bis and 3406bis

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Feb 2013 22:13:22 -0700

Juha, my apologies for the delayed reply. One question inline about
query components.

On 12/21/12 12:10 AM, Juha Hakala wrote:
> 
> On 27.11.2012 22:37, Andrew Newton wrote:

<snip/>

>> It should be noted that these new documents are not the final
>> output of this working group but are simply a new basis for the
>> development of the milestones we must achieve, and they will be
>> based on consensus within this working group and the IETF in
>> accordance with IETF practices.
> 
> I hope the WG will succeed in this task, and wish it would have
> been possible to find consensus on how to use fragment and query.
> Since this did not seem likely, the Finnish ISO TC 46 shadow
> committee decided in its meeting 2012-12-10 to start the
> development of a national URN syntax standard. The standard will be
> bilingual (English and Finnish) and it will be based on the latest
> 2141bis version Alfred Hoenes wrote. Our intention is to keep the
> document downward compatible with whatever the URNbis WG will come
> up with.

Could you explain a bit more clearly the intended usage of query
components in URNs? As far as I have been able to determine, no one
has proposed to include query components in URNs themselves (e.g.,
"urn:isbn:978-951-1-25645-8?param=value"), only in URIs (mostly HTTP
URIs) that encapsulate such a URN for resolution purposes and then
append a query component to the end of the URI (say,
"http://resolver.example.com/urn:isbn:978-951-1-25645-8?param=value").
Does the Finnish ISO TC 46 shadow committee plan to proceed along the
URI path, or do they plan to include query components in URNs themselves?

Could you also explain (perhaps in a separate thread) the intended use
of the fragment identifier, as well as any other discrepancies between
the shadow committee's approach and 2141bis and 3406bis as they stand
today?

Many thanks,

Peter

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

---

From: Juha Hakala <[email-masked]>
Date: Thu, 21 Feb 2013 09:05:43 +0200

Hello Peter; all,

See the answers below.

> URI path, or do they plan to include query components in URNs themselves?
The plan is to continue the work started in URNBIS by Alfred Hoenes and 
others. That is, query components will not be a part of the URN 
(namespace specific string). They will always be added only after the 
URN has been assigned (by the publisher or somebody else), by e.g. the 
user requesting a resolution service, such as URI to URL as specified in 
RFC 2483.

Typical use cases include a user who wants metadata about a book before 
e.g. purchasing or borrowing it; a user who wants to see the copyright 
statement of a video; a user who wants to see all the available variant 
versions (e.g. PDF, EPUB 3, OOXML and so on) of the article she wants to 
read; a user who wants to check with the help of preservation metadata 
what kind of differences there are in the look and feel between the 
oldest and subsequent versions of a still image. Since long term 
preservation of digital resources will be primarily based on migration, 
in due time there will be n versions available for each resource that 
has been available long enough (please remember that the time scale the 
national libraries are talking about is centuries, not decades). In this 
complex environment the digital archivists in national libraries, 
national archives etc. will need persistent identifiers and services 
provided by URN resolution.  Being able to use query to ask for these 
services looks like a preferred way to move on.

  There are several reasons why query components cannot be part of the 
URN. From the formal point of view, most standard identifier systems do 
not allow adding anything to namespace specific string. From practical 
point of view, services depend on the technical infrastructure and will 
change over time. For instance, the list of services in RFC 2483 is 
insufficient and some of the services (especially URI to URC and URI to 
URCs) need service parameters; in the case of the above mentioned 
services, a user must be able to specify his metadata format preference. 
There is no way to specify a priori all the different query elements 
that can be attached to a URN.

There are many ways in which service requests can be passed to the URN 
resolution service which will process them. IMHO the most convenient one 
is the query, now that RFC 3986 allows it. When the first set of URN 
RFCs was developed, this was not an option and workaround was developed; 
alas, DDDS as specified in RFC3401 etc. has never really become 
popular.  In order to prevent proliferation of local query 
specifications, it is necessary to create a (global / public) registry 
which specifies the services and their parameters. Such registry would 
also provide a simple means for adding new services and service 
parameters; trying to nail them down in an RFC (as in RFC 2483) would 
only lead to constant need for updating that RFC when new kind of 
services emerge in the Internet / Web.

So our plan is - if query is not incorporated in the official IETF URN 
syntax - to extend the IETF specification, and lay basis for a Finnish 
registry for URN resolution services. Of course we would prefer to have 
query (and fragment) included in the official IETF URN syntax. IMHO, f 
the aim is to align URNs with RFC 3986, incorporating both query and 
fragment usage into the URN syntax should be the URNBIS aim as well.
> the shadow committee's approach and 2141bis and 3406bis as they stand
Will do that.

All the best,

Juha
>
> Many thanks,
>
> 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/
>
> iQIcBAEBAgAGBQJRJazyAAoJEOoGpJErxa2p+9IQAKeLUaovxAC6J1kmYFO6wYOi
> MMM+3ywObqB64iz2AgHVt0hq2fWO+B1GvlDWmEAiQZcQkDHICYkqSawyJrYqKU8O
> ljP7+19VlqbfvzOFuNJvo6FbnrVBTo3bcT0yKqqTt8EpI0qD7DE7yo8D1FfbOj1V
> 27Q5ydkK5tl2dagzkNYlgFj2cNRwluFCZvtSd0RZI/MrOd0IxD5GXZ1g4gOjRi9Q
> ZQkvQ0BliFaxbPGmJjtfIV9e2KotpPfRBjSf8Q+p9ETTt/3VMEHaa+VubMQeYy9N
> df/pJtAZMQAzrl+6zVgY3CR+LTUIX8zdUJ6DMs8wBSKhH3CgUz1rppKB7cAUulsB
> ZXPvl1oTstyYZHrbkicKed5MUA0yw5MZMYkRygcCWZx8wejM5RfXjVRMKHdDiTPO
> kH3s53hpk8+yyvfMkzWI8KIjErzW+ZJfW4Jq4SVgDcn/jLf0pB7Q3bAQCW4nw7J4
> oSTsFyPB+BJYy3cW+CSbbW9DzgmUyUtJcsEs/I9WyWr3ILNFiN+/1dC3pvS1A+N9
> GCGZ7iDm7E2r8uLbiEkmjiEvOP5ngbfmIdfEn/Z4anmytWMFv4+DJ5d+jTuEeHbV
> jyHc40eFGEGfTKMVJHFU8koZ4Lc/tf1figiWvvMmnIVECT3ttJke+kIf4vo8wW/+
> dfZU65edw2k1eBmeKkwA
> =5mpd
> -----END PGP SIGNATURE-----

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503)
  FIN-00014 Helsinki University
  tel +358 9 191 44293

---

From: Andrew Newton <[email-masked]>
Date: Thu, 21 Feb 2013 10:34:22 -0500

On Thu, Feb 21, 2013 at 2:05 AM, Juha Hakala <[email-masked]>wrote:

> resolution service which will process them. IMHO the most convenient one is
> the query, now that RFC 3986 allows it. When the first set of URN RFCs was
> developed, this was not an option and workaround was developed; alas, DDDS
> as specified in RFC3401 etc. has never really become popular.

I know we've had a lot of conversations about fragments, but I don't think
adding query components has been discussed much here. Are there any
specific objection to adding query to the URN syntax?

-andy

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 21 Feb 2013 19:51:48 -0700

On 2/21/13 12:05 AM, Juha Hakala wrote:
>> components in URNs? As far as I have been able to determine, no
>> one has proposed to include query components in URNs themselves
>> (e.g., "urn:isbn:978-951-1-25645-8?param=value"), only in URIs
>> (mostly HTTP URIs) that encapsulate such a URN for resolution
>> purposes and then append a query component to the end of the URI
>> (say, 
> The plan is to continue the work started in URNBIS by Alfred Hoenes
> and others. That is, query components will not be a part of the
> URN (namespace specific string). They will always be added only
> after the URN has been assigned (by the publisher or somebody
> else), by e.g. the user requesting a resolution service, such as
> URI to URL as specified in RFC 2483.
> 
> Typical use cases include a user who wants metadata about a book
> before e.g. purchasing or borrowing it; a user who wants to see the
> copyright statement of a video; a user who wants to see all the
> available variant versions (e.g. PDF, EPUB 3, OOXML and so on) of
> the article she wants to read; a user who wants to check with the
> help of preservation metadata what kind of differences there are in
> the look and feel between the oldest and subsequent versions of a
> still image. Since long term preservation of digital resources will
> be primarily based on migration, in due time there will be n
> versions available for each resource that has been available long
> enough (please remember that the time scale the national libraries
> are talking about is centuries, not decades). In this complex
> environment the digital archivists in national libraries, national
> archives etc. will need persistent identifiers and services 
> provided by URN resolution.  Being able to use query to ask for
> these services looks like a preferred way to move on.
> 
> There are several reasons why query components cannot be part of
> the URN. From the formal point of view, most standard identifier
> systems do not allow adding anything to namespace specific string.
> From practical point of view, services depend on the technical
> infrastructure and will change over time. For instance, the list of
> services in RFC 2483 is insufficient and some of the services
> (especially URI to URC and URI to URCs) need service parameters; in
> the case of the above mentioned services, a user must be able to
> specify his metadata format preference. There is no way to specify
> a priori all the different query elements that can be attached to a
> URN.
> 
> There are many ways in which service requests can be passed to the
> URN resolution service which will process them. IMHO the most
> convenient one is the query, now that RFC 3986 allows it. When the
> first set of URN RFCs was developed, this was not an option and
> workaround was developed; alas, DDDS as specified in RFC3401 etc.
> has never really become popular.  In order to prevent proliferation
> of local query specifications, it is necessary to create a (global
> / public) registry which specifies the services and their
> parameters. Such registry would also provide a simple means for
> adding new services and service parameters; trying to nail them
> down in an RFC (as in RFC 2483) would only lead to constant need
> for updating that RFC when new kind of services emerge in the
> Internet / Web.
> 
> So our plan is - if query is not incorporated in the official IETF
> URN syntax - to extend the IETF specification, and lay basis for a
> Finnish registry for URN resolution services. Of course we would
> prefer to have query (and fragment) included in the official IETF
> URN syntax. IMHO, f the aim is to align URNs with RFC 3986,
> incorporating both query and fragment usage into the URN syntax
> should be the URNBIS aim as well.

Juha, I am confused. First you say that "There are several reasons why
query components cannot be part of the URN." Then you say that service
parameters will be passed to URN resolution services using query
components. Do you propose that service parameters will be passed by
appending them to the URN but not as part of the URN itself? Do you
have examples of what that would look like? My impression from your
earlier messages was that the parameters would be passed in the query
component of a URI, such as:

http://resolver.example.com/urn:isbn:some-number?param=value

But in that case the query component is not part of the URN, it is
part of the URI. And if that's what you are proposing, then URNs still
don't have query components. If I'm missing something here, please do
tell.

Peter

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