Subject: [urn] Consensus Question Regarding Direction of Work

From: Andrew Newton <[email-masked]>
Date: Tue, 5 Aug 2014 11:50:34 -0400

During our recently completed meeting in Toronto at IETF 90, we
achieved necessary consensus from the meeting participants to focus
our energies on the semantics of the components of URNs with a hopeful
goal of keeping syntax compatible with URIs. In other words, the
separation of URNs from URIs is to be about semantics instead of
syntax (the implication being that we are not wholly separating URNs
from URIs).

The driving mechanism for this work will be a revision to the
separation Internet-Draft as mentioned by John Klensin. That draft may
or may not turn into an RFC depending on the needed changes to
2141bis.

As is IETF practice, I am seeking input from individuals on this
mailing list regarding this decision. Specifically, I am seeking
objections that have not been previously raised.

-andy
co-chair

---

From: [email-masked] (Henry S. Thompson)
Date: Tue, 05 Aug 2014 17:04:49 +0100

Andrew Newton <[email-masked]> writes:

> goal of keeping syntax compatible with URIs.

That's hopeful.

> ...

> I am seeking input from individuals on this mailing list regarding
> this decision. Specifically, I am seeking objections that have not
> been previously raised.

I support this decision.  I continue to think that the key to making
progress is a careful focus on what it is that the constituency
seeking changes need URNs to _do_ for them, and that pretty much
accords with the consensus you report above.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 5 Aug 2014 14:03:18 -0400

> From: Andrew Newton <[email-masked]>
> 

I agree that is a good way to progress.  Maintaining syntactic
compatibility is an important feature, but we have a great deal more
freedom regarding semantics.

As Henry Thompson said, it's important to get input regarding "what it
is that the constituency seeking changes need[s] URNs to _do_ for
them".

Dale

---

From: Juha Hakala <[email-masked]>
Date: Wed, 06 Aug 2014 11:02:15 +0300

Hello Andy,

I am glad that the meeting in Toronto was productive.

> freedom regarding semantics.

+ 1.

It should be possible to achieve what the developers of the URN-based 
systems need just by adjusting semantics. Accommodating semantic 
requirements of the identifier systems expressed as URNs is, at least in 
principle, easy: Namespace Specific String should contain only the 
identifier itself (in an encoded form, if necessary); nothing more, 
nothing less.
> is that the constituency seeking changes need[s] URNs to _do_ for

To name the two most important practical things, we need to be able to
- use URI query to pass resolution related parameters to URN resolvers, and
- use URI fragment to enable citing / referencing of identified resources.

This can be done iff we agree that query and fragment are not part of 
the NSS (that is, in the URN context they do not identify anything).

As an extra bonus, alignment of the URN syntax with the URI syntax 
should remove the impression that URNs are out of date or deprecated by 
URIs.

Juha

>
> Dale
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  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: Keith Moore <[email-masked]>
Date: Wed, 06 Aug 2014 13:16:59 -0400

On 08/06/2014 04:02 AM, Juha Hakala wrote:
> requirements of the identifier systems expressed as URNs is, at least 
> in principle, easy: Namespace Specific String should contain only the 

I agree with the last sentence.

> - use URI query to pass resolution related parameters to URN 

I understand the desire to pass parameters to resolvers, but (a) why 
does this need to use URI query syntax, and (b) why does this need to be 
bundled with the URN at all?   (since it's not referencing a portion of 
the resource, but really, a completely different resource)

Or maybe I misunderstand what you mean by "pass parameters to 
resolvers"?   Broadly speaking, I can imagine two different kinds of 
parameters:

1) parameters that identify some attribute of a resource that 
essentially narrows the scope to a portion of the resource - e.g. a 
particular version, edition, chapter, language, page range, time code 
range, etc. of a resource that exists in multiple versions (all grouped 
under this URN) and/or for which it makes sense for a specific portion 
to be referenced.

2) parameters that ask the resolver to produce some different resource 
than that named by the URN - e.g. a description of the resource rather 
than the resource itself, or a related resource

The first kind of parameter is what I've been thinking of as a 
"facet".   The combination of the URN and the parameter(s) still refer 
to either the entire resource or some narrowed portion of what is 
included in the resource.

The second kind of parameter turns the original URN into a name for 
something else entirely, even though at some level both kinds of 
parameter end up just being passed to the resolver for interpretation.

I think it might be useful to distinguish between these two, both in 
discussions and in syntax.

> - use URI fragment to enable citing / referencing of identified resources.

Again, why does this need to overload URI fragment syntax?

> the NSS (that is, in the URN context they do not identify anything).

I think we should agree on that in any event.   But again, defining what 
is or is not "part of" the URN or NSS might less important than 
describing how systems should actually process such identifiers.

> should remove the impression that URNs are out of date or deprecated 
> by URIs.

That impression, I believe, has nothing to do with syntax, and 
everything to do with differences in architectural philosophy. It's 
possible that trying to shoehorn URNs into URI syntax will actually 
cause more confusion and help to further the arguments that some people 
make that URNs are not needed.   But I think we should focus primarily 
on what makes sense from a protocol perspective and try to not worry too 
much about philosophical /political battles.

Keith

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 6 Aug 2014 16:53:34 -0400

> From: Keith Moore <[email-masked]>

> Again, why does this need to overload URI fragment syntax?

I believe that what Juha means is that if urn:isbn:1234 is the name of
a book, then urn:isbn:1234#page7 can be the name of a page of the
book.  Currently, using '#' at all with URNs is not syntactally
allowed by the URN RFC, though it's within the syntax looking at them
as URIs (and hence is unlikely to cause ugly compatibility problems).

I think the tricky part is that currently the effect of fragment
identifiers is entirely defined within the media type definition.
Whereas, one wants to be able to define all manifestations of the
resource to have "#act2scene3" refer to the same logical point in the
resource (from the human point of view), which may not be operable
within the interpretation of fragment identifiers that was defined by
some particular manifestation's media type.

Dale

---

From: [email-masked] (Henry S. Thompson)
Date: Wed, 06 Aug 2014 22:48:29 +0100

> - use URI fragment to enable citing / referencing of identified resources.

Trying to be careful here: those read to me as candidate solutions to
unstated requirements, not the requirements themselves, which is what
I intended to ask for.

Would these be acceptable formulations of the _requirements_ (I'm
guessing here, help me out):

 1) Given a URN which identifies a publication, it should be possible
    to construct another URN which identifies specific aspects of the
    metadata for that publication, such that the right thing will
    happen if the resulting URN is resolved;

 2) Given a URN which identifies a publication, it should be possible
    to construct another URN which identifies a specific sub-part of
    that publication.

I'm assuming that the details of _how_ to do the above constructions
wants to be included in URN namespace registrations.

Examples would help.  Not examples of _syntax_ so much, as examples of
the requirements, e.g. for (2):

  "Given a urn:isbn:... URN which identifies a book, it should be
   possible to construct a URN which identifies a chapter of said book
   by number or name."

and for (1)

   "Given a urn:isbn:... URN, it should be possible to construct a
    URN which can be used for retrieval of the name of the
    ISBN-registered publisher of the publication that the original URN
    identifies, given access to a conformant generic
    urn:isbn:.... resolution service."

It would be helpful also to understand if those requirements have to
be satisfied uniformly for _all_ URNs, or whether it's up to a URN
namespace registration to specify whether, and if so how, (1) and/or
(2) are to be achieved (possibly subject to some general guidelines
for all URNs).

Thanks,

ht

---

From: Andrew Newton <[email-masked]>
Date: Wed, 6 Aug 2014 18:24:29 -0400

> (2) are to be achieved (possibly subject to some general guidelines

I agree.

But I'd appreciate if we could keep this thread dedicated to hearing
from those with concerns regarding the direction this working group
intends to take (not to pick on Henry though).

I'll be working with the draft author on a structured discussion to
help us get these types of answers. The revised draft will be our
anchor point for discussion, and that will be come soon if no
objections are raised.

-andy
co-chair

---

From: [email-masked] (Henry S. Thompson)
Date: Wed, 06 Aug 2014 23:45:20 +0100

> intends to take (not to pick on Henry though).

Not to be awkward, but if the direction the working group intends to
take is substantially determined along the following lines (quoting
from [1]):

then I'm _not_ happy with its direction.  A working group to address
requirements on URNs not currently (perceived) to be met is one
thing.  A working group to implement a particular pair of solutions is
quite another.

Either way, I've made my position clear, I won't pursue this further

ht

[1] http://www.ietf.org/mail-archive/web/urn/current/msg02429.html

---

From: Juha Hakala <[email-masked]>
Date: Thu, 07 Aug 2014 08:36:05 +0300

Hello Henry,

>      happen if the resulting URN is resolved;

RFC 2483 specifies URI to URC service, which:

    ... allows the client to obtain a description of the resource
    identified by a URI, as opposed to the resource itself or simply the
    resource's URLs. The description might be a bibliographic citation, a
    digital signature, or a revision history. This memo does not specify
    the content of any response to a URC request. That content is
    expected to vary from one server to another.

So, we might have a requirement to support URI to URC, but in an updated 
form so that it is possible to specify the metadata format. IMO there is 
no need to go further and allow retrieval of individual metadata elements.

It is my intention to revise RFC 2483 since several relevant services 
are missing from it, and we also need a simple mechanism for specifying 
additional services and service parameters (such as metadata formats to 
URI to URC).

The implementer community has a requirement for these additional 
services missing from RFC 2483, but more urgently, we need a simple 
mechanism for passing service parameters to resolvers. DDDS, specified 
in RFCs 3401-3404, has for some reason not been implemented in URN 
resolvers. Instead, the community developing these applications wishes 
to follow the example of ARK and Handle/DOI communities - use query for 
sending service requests to resolvers.

>      to construct another URN which identifies a specific sub-part of
This requirement has to do with identifier assignment policies which 
differ from one namespace to the next.  I don't think that IETF or 
URNBIS can change the existing identification practices. You just have 
to accept them, since that's how the URN system has been designed. It 
was a brilliant idea to establish namespaces which each apply the rules 
of the registered identifier system. But that means that while there are 
some namespaces where it may be possible to meet this requirement, there 
are also some where it is not possible.

It is important to make a difference between logical and physical 
components of publications. URNBIS has agreed earlier that 
identification of logical components will be based on namespace specific 
principles and practices. For instance, in the ISBN namespace, separate 
ISBNs can be given both to The Lord of the Rings as a whole, and to the 
three parts (when they are published individually). But it is not 
possible to assign ISBNs to individual chapters, unless they are 
published separately.

Two or more identifier systems may be used in parallel to identify all 
logical components needed. An example of this is that ISSN is used for 
identification of serials, but DOI for identification of individual 
articles. Or, we have ISBN for a digitized book, but NBNs for page images.

URI fragments may or may not have anything to do with the logical 
structure of the work. Therefore it is very unclear from the start what 
fragments might identify. On the other hand, users may want to use them 
for citing and referencing purposes. We can allow this by saying that 
when used in the URN context they do not identify anything ( of URN 
implementers). Then we avoid also two further problems:

- mixing identification of logical and physical components of a 
publication in one URN
- extending the scope of existing identifiers beyond what is acceptable

> wants to be included in URN namespace registrations.

IETF has decided to allow also namespaces which do not support any 
resolution services. If one or more services are supported, they may be 
listed to registration requests, alongside an explanation of the 
process. But is should be noted that maintaining this information would 
be cumbersome; services supported depend mainly on the technical 
infrastructure within which identifiers are used. So when for instance 
digital preservation systems become common in a few years time, a lot of 
new resolution services will be available for many identifier systems.

Namespace registrations should include the scope of the system (what can 
be identified).

>     possible to construct a URN which identifies a chapter of said book

Requirements concerning the identification policies (especially as 
regards logical components of resources) are usually maintained by the 
identifier user communities in manuals and user guides. IETF does not 
need to go into this area, and it certainly cannot make requirements 
which are in conflict with existing practices.

What IETF should do is to allow usage of URI fragment for indicating 
(not identifying) physical components of identified resources.

>      urn:isbn:.... resolution service."

Given the background provided in RFC 2483, we could perhaps say 
something like this:

URN resolver should be able to resolve urn + (valid) service request 
into appropriate URI and pass it on to a server which can provide the 
service required. For instance, if resolver receives a URN with a query 
containing URI to URC request, the resolver should convert that request 
into e.g. SRU search, and send it to a bibliographic database which is 
able to deliver metadata about the resource to the client application.

> (2) are to be achieved (possibly subject to some general guidelines

IMO nothing applies to all URNs. If a URN is not actionable, then 
nothing we say about services is relevant. And if URN does not identify 
a publication but (for instance) a person, there are neither logical or 
physical components to identify / indicate.

As regards query, we cannot carve in stone the services and service 
parameters supported by a namespace. There are services (for instance, 
retrieve the original version of this digital document) which cannot be 
supported now, but which will become very relevant (and possible) in a 
few decades.

Best regards,

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: Juha Hakala <[email-masked]>
Date: Thu, 07 Aug 2014 09:04:44 +0300

Hello,

> as URIs (and hence is unlikely to cause ugly compatibility problems).

Correct, except that although urn:isbn:<isbn> is the name / identifier 
of a book, urn:isbn:<isbn>#page7 cannot be the name / identifier of page 
7. The identifier (namespace specific string) is the same in both 
examples. In the latter URN there is a fragment after NSS indicating a 
certain location within the document, but the two URNs are still 
lexically equivalent.

Of course, you could do something like urn:xxxx:<isbn#page7> but IMO 
this is not a good idea (see below).

Within the URN system namespaces, the rules of identifier systems apply. 
These rules may or may not agree with URI Generic Syntax. The important 
thing is that the ISBN user manual overrides what RFC 3986 says about 
the role of fragments in identification.

The good thing is that this mismatch between RFC 3986 and ISBN rules 
relate only to semantics, not syntax.

> some particular manifestation's media type.

Yes, we need to keep identification of logical parts of resources and 
usage of URI fragment apart. Even if the logical structure of a document 
happens to match the physical one, it is better to avoid URI fragment 
usage, since the next (migrated) version of the document may not have 
the same encoding any more. Fragments are tied to a single manifestation 
of a resource and do not live longer than that manifestation (whereas 
the work itself may live much longer in various migrated forms).

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: Juha Hakala <[email-masked]>
Date: Thu, 07 Aug 2014 10:23:27 +0300

Hello Keith,

> does this need to use URI query syntax, and (b) why does this need to 
> be bundled with the URN at all?   (since it's not referencing a 
> portion of the resource, but really, a completely different resource)

Based on the implementer experiences of other persistent identifier 
communities, using query for this purpose seems to be a simple and 
efficient means for making service requests. Moreover, implementing some 
other method would make it more difficult to make ARK / Handle / URN 
resolvers interoperable.

Once this kind of usage of query in the URN context is approved, there 
is a need to specify syntax (e.g. ?s=URC) the implementers should use in 
order to guarantee maximum interoperability between different resolver 
applications.

> range, etc. of a resource that exists in multiple versions (all 
> grouped under this URN) and/or for which it makes sense for a specific 
> portion to be referenced.

Like URI fragment, query does not identify anything and it cannot / 
should not be used for this purpose.

> than the resource itself, or a related resource

Yes, we want to use query to help us to implement services specified in 
RFC 2483 (and other services which have not been specified yet.

> parameter end up just being passed to the resolver for interpretation.

Since query is not part of the NSS, the original URN and the URN with 
query identify the same thing (that is, they are lexically equivalent).

In many URN namespaces, it is impossible to extend the scope of the 
identifier in the manner URI query would require. But even if the 
namespace were so liberal as to approve query usage in identification, 
"name for something else entirely" would become a major problem. In my 
opinion, saying that URI query identifies something just cannot be right 
in any context. Also, while NSS is unique and persistent, query will not 
be. Services and service parameters come and go; at the moment it would 
make sense to require metadata about a book in MARC 21 format from a 
library system, but in 20 years time the format will have changed.

> discussions and in syntax.

Yes - we only need to discuss about the latter in the URN context.

> Again, why does this need to overload URI fragment syntax?

I do not think that allowing the use of fragments with URNs overloads 
the URI fragment syntax.

People are already using URLs and fragments to cite / refer to digital 
documents. Using URN + fragment for this purpose is less error prone, 
although citing / referencing digital resources like this assumes that 
the identified manifestation of the resource will remain available for a 
long time. Depending on the MIME type of the resource (and 
organizational set-up of the document repository) that may be a wrong 
assumption.

Citing / referencing digital documents so that the links will be truly 
persistent is difficult. The best solution will eventually be to create 
from a reference a link to the metadata record of the work (which should 
contain links to all the physical manifestations, from the earliest one 
to more modern migrated versions). Any location information should be 
based on logical fragments such as chapters, not physical fragments such 
as pages.

Juha

> I think we should agree on that in any event.   But again, defining 
> what is or is not "part of" the URN or NSS might less important than 
> cause more confusion and help to further the arguments that some 
> people make that URNs are not needed.   But I think we should focus 
> primarily on what makes sense from a protocol perspective and try to 
> not worry too much about philosophical /political battles.
>
> Keith
>

-- 

  Juha Hakala
  Senior advisor

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Aug 2014 09:53:23 -0400

On 08/07/2014 02:04 AM, Juha Hakala wrote:
> of a book, urn:isbn:<isbn>#page7 cannot be the name / identifier of 
> page 7. The identifier (namespace specific string) is the same in both 

Ok, first, I propose that we talk in terms of "extended URNs" that 
consist of a URN + an optional modifier.   Something like:

extended-urn = urn [ modifiers ]

modifiers =  *( "/" facet-name "=" value ) *( "?" string ) [ "#" string ]

The precise details of the syntax aren't important for the moment. 
What's important is that:

- an extended URN consists of a URN + zero or more modifiers
- every URN is an extended URN, but an extended URN that includes a 
modifier is necessarily a URN
- an extended URN is a URI, and can potentially be used anywhere a URI 
can be used

So using the example above: "urn:isbn:1237#page7" would be an extended 
URN.   That extended URN contains an embedded URN "urn:isbn:1237".   The 
"#page7" modifier is "part of" the extended URN, but not "part of" the URN.

(Whether or not it's a good idea to use "#" with URNs in this way, or to 
use the idea of HTML-style fragment identifiers to name pages, are 
separate questions.)

(And I'm not entirely happy with the name "extended URN" but it's the 
best I could think of for the moment.)

> Within the URN system namespaces, the rules of identifier systems 
> apply. These rules may or may not agree with URI Generic Syntax. The 
> important thing is that the ISBN user manual overrides what RFC 3986 
> says about the role of fragments in identification.

URN namespaces should not be able to redefine URI syntax on a 
per-namespace basis.   A parser must be able to recognize where a URI 
ends (even in, say, an email message or text document) without knowing 
the syntax of each separate URI namespace.

If 3986 needs to be overridden for all URNs, or to accommodate extended 
URNs, fine.   But it must not be a namespace-specific syntax.

Furthermore, the meaning of fragment syntax must not be 
namespace-specific, because this would again require that clients know 
details of individual URN namespaces.   Fragment syntax must have the 
same meaning across all URNs.

Actually I think fragment syntax should have the same meaning across all 
URIs, that this is already defined (for better or worse) as being 
specific to the media type, and that this is too well-established to 
change it.   At the very least we need to consider not only the desire 
of people to include fragment-like specifiers with URNs but also the 
potential impact on all of the software that currently exists that 
processes URIs.

> usage of URI fragment apart. Even if the logical structure of a 
> document happens to match the physical one, it is better to avoid URI 
> fragment usage, since the next (migrated) version of the document may 
> not have the same encoding any more. Fragments are tied to a single 
> manifestation of a resource and do not live longer than that 
> manifestation (whereas the work itself may live much longer in various 
> migrated forms).

I think we are going to have to reconcile ourselves to the fact that 
"extended URNs" have no assurance of persistence even though the URNs 
embedded in them do.   So it doesn't violate any persistence rules to 
use an extended URN with an HTML-style fragment.

(This makes me uncomfortable, as I think that no matter what we write in 
our RFCs, ordinary users are going to miss the subtle distinction 
between a URN and an extended URN.  They're still going to think of the 
modifiers as "part of the URN".   But I think there's too much demand to 
be able to use modifiers with URNs in ways that that result in the 
combinations of the two being non-persistent.    We could of course 
define a different URI scheme, say "xurn:", to make the difference more 
apparent.  But I think people would still get URNs and XURNs confused, 
and use the wrong prefix, and software would end up treating both the same.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Aug 2014 10:39:13 -0400

Oops....I just noticed an important error in the text below.

> modifier is necessarily a URN

the above line should be:

modifier is NOT a URN

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Aug 2014 10:44:47 -0400

On 08/07/2014 03:23 AM, Juha Hakala wrote:
> efficient means for making service requests. Moreover, implementing 
> some other method would make it more difficult to make ARK / Handle / 
> URN resolvers interoperable.

I don't think this is a good enough reason to overload query syntax.

Or perhaps I should rephrase the question: Why is it more important to 
use URI query syntax to pass parameters to URN resolvers, than it is to 
be able to use URI query syntax to pass messages to the resources named 
by those URNs?   Because we know from vast experience that it's 
tremendously useful to be able to bundle a URI that identifies a 
resource with a message that gets passed to that resource and which 
potentially affects the information returned by that resource.   It's 
probably not a stretch to estimate that nearly every web server provides 
access to a few resources that work this way.

To me it also seems incredibly shortsighted to define query syntax with 
URNs in such a way as to preclude being able to bundle a message to be 
passed to the resource, with the URN.   That would essentially be saying 
that it's more important to optimize URNs to work with fixed/physical 
media resources than to optimize URNs to work with network-connected 
resources... which is indeed odd considering that URNs were created 
primarily for the latter purpose.

Or to put it another way: URI syntax (as defined and in practice) really 
limits the number of modifiers with which URIs can be bundled, and 
doesn't leave much room for extensibility.   Do we really want to 
restrict the use of "?" with URNs in such a way that the only thing that 
can be done with it is to pass parameters to a resolver?   I think I 
understand why people want to bundle resolver queries with URNs, but I 
also think that that's about the least compelling use case I can think 
of for attaching modifiers to a URN.   Certainly it seems less 
compelling than wanting to narrow the resource being named to a 
particular facet of that resource like chapter or edition or language or 
timecode range, and less compelling than wanting to include a 
message/query to be sent to the resource.   Still, I don't want to say 
"you cannot bundle a resolver query with a URN".  I am just saying 
"please, let's define a way to do that, that doesn't prevent other kinds 
of modifiers to be bundled with URNs".

So I think we should try to define URN modifiers in such a way that 
there's some room for expansion, as we will surely discover new 
compelling use cases in the future.   Simply redefining "?" and "#" to 
have different meanings than for other URIs, while being consistent with 
syntax for other URIs, won't leave room for expansion.   I want us to 
define an extensible syntax for URN modifiers, such that a client can 
tell which modifiers are resolver queries, which ones are facets that 
narrow the resource being named, and so forth.   And I want to do it in 
such a way that doesn't break existing things that understand URIs.

> is a need to specify syntax (e.g. ?s=URC) the implementers should use 
> in order to guarantee maximum interoperability between different 
> resolver applications.
>
>>
>> grouped under this URN) and/or for which it makes sense for a 
>> specific portion to be referenced.
>

I was just talking about use cases for passing parameters to 
resolvers.   I wasn't speaking in terms of query syntax.   I don't think 
it's a good idea to use query syntax for either of these use cases.

>
>>
>> 2) parameters that ask the resolver to produce some different 
>> resource than that named by the URN - e.g. a description of the 
>> resource rather than the resource itself, or a related resource
>
> Yes, we want to use query to help us to implement services specified 
> in RFC 2483 (and other services which have not been specified yet.

I also want people to be able to implement those services.   That 
doesn't mean that I think it's a good idea to use query syntax for this 
purpose.

>> "facet".   The combination of the URN and the parameter(s) still 
>> refer to either the entire resource or some narrowed portion of what 
>> is included in the resource.
>>

Well, no.   They both contain the same URN, but it's misleading at best 
to say that the two are equivalent.    You should not, for instance, 
treat them as equivalent for the purpose of caching the result.   
Equivalence is probably not a very useful concept when talking about 
extended URNs.    You can compare the URNs embedded in them, and that 
might occasionally be useful.    But comparing two extended URNs in 
their entirety probably won't be useful for much.

> opinion, saying that URI query identifies something just cannot be 
> right in any context.

This probably a minor point, but I disagree.  It's reasonable to say 
that an HTTP URL with a query identifies something, and it's as 
reasonable to say that a URN with a query identifies something. It's not 
reasonable to assume in either case that the binding between the URI and 
what is identified, is persistent.

>
> Also, while NSS is unique and persistent, query will not be. Services 
> and service parameters come and go; at the moment it would make sense 
> to require metadata about a book in MARC 21 format from a library 
> system, but in 20 years time the format will have changed.

Agree.
> Yes - we only need to discuss about the latter in the URN context.

Strongly disagree.  I see too many uses of "?" to identify facets of 
resources with HTTP, to believe that it's unimportant to be able to 
specify facets with URNs.   We need a way to do that with URNs, whether 
or not it uses "?".   |

I would be happy for URNs to accommodate both of the above use cases.   
But as far as I can tell, the former use case is much more compelling 
than the latter.

> I do not think that allowing the use of fragments with URNs overloads 

The current meaning of fragment syntax is defined by the media type, and 
fragments are evaluated according to the rules of the media type.  If 
you are proposing to do it differently for URNs, that's overloading the 
syntax.

Now, having said that, I'll readily admit that HTML fragments are really 
poorly designed and not terribly useful.   And I haven't seen fragments 
used frequently with other kinds of media, so I don't know how useful 
they are with other media types.   But I think it's possible to do a 
better job than what was done with HTML.

The point is, if we're going to change what fragment syntax means in the 
context of URNs, it's going to potentially break a lot of software out 
there that thinks it knows how to interpret "#" in the context of 
URIs.   We need a really good reason to do this.   At a minimum, we need 
to redefine fragments in a way that works a lot better than it does with 
HTML.

One problem with HTML fragments is that because of how they're defined 
and implemented, they're inherently restricted to the context of a 
particular "file" or "page".   The client generally has to download the 
entire "page" before it can search for the specific fragment that was 
requested.   This works marginally well for relatively small text files, 
horribly for many other kinds of media, like large video programs.    
Another problem with HTML-style fragments is that they're restricted to 
regions of a document that don't overlap the boundaries of other 
portions of the document hierarchy.   So while you can have a fragment 
that only consists of a portion of a paragraph, you can't have a 
fragment that consists of the end of one paragraph followed by the start 
of the next.  Nor can you have two fragments that overlap each other 
unless one is a strict subset of the other.   Nor can a fragment contain 
sections of multiple files, even though it's quite common to represent a 
single document as large numbers of HTML files.   And fragment names are 
arbitrary - there's no controlled vocabulary for them so there's no 
portable way to talk about volumes or chapters or sections or pages or 
timecode ranges, etc.   And there are many other limitations of HTML's 
way of defining fragments.

So if we're going to redefine how fragments work in the context of URNs, 
let's do it in a way that makes them a lot more flexible and broadly 
applicable.   At the very least it should be possible to pass a fragment 
identifier to a resolver, and for that resolver to be able to say "in 
order to find the specific fragment you're interested in, you need to 
download only this one file rather than all of the files associated with 
the resource".  Or maybe "in order to find the fragment X, pass query 
parameter Y to the resource". And in the absence of any specific 
instructions from the resolver, fragment processing should fall back to 
the current behavior.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Aug 2014 11:01:58 -0400

> URN resolvers interoperable.

One more thing.   I don't think it's at all necessary for URN modifier 
syntax to be consistent with ARK, Handle, DOI, etc. modifier syntax.

Widespread existing practice, standards, and history dating to the 
beginning of the web, all consistently are that interpretation of "?" is 
specific to the URI scheme.

A client implementation is going to treat each URI scheme separately.  
Once it identifies the beginning and end of a URI, the next thing it 
does is look at the scheme name, and from the scheme name it knows how 
to interpret the rest of the URI.   There should be no expectation that 
the client code to handle URNs is the same as the code to handle Handles 
or other persistent identifiers.

Even if there are resolvers that can handle multiple kinds of persistent 
identifiers (and I can certainly see that this would be useful), there's 
no reason to impose the same syntax rules on all of those identifiers.   
The URI scheme-specific code in each client can manage the details of 
parsing each kind of URI, identifying the relevant portions of each, and 
converting those data to a query to be sent to the resolver.   I can see 
where it would be useful to agree on common vocabulary and semantics for 
different resolver query parameters across the different kinds of 
persistent URIs, but forcing all of those URIs into the same syntax 
seems like a bad idea.

More broadly, the other persistent URI schemes, for better or worse, 
chose to go their own way rather than to be URN namespaces. Presumably 
they had their reasons for doing so, and I won't try to second-guess 
them.   But it seems likely that at least some of them didn't want to 
adhere to quite the same set of constraints as are imposed on URNs, and 
maybe they wanted to impose some constraints that URNs don't impose.    
Or maybe they had somewhat different scopes in mind for what they were 
trying to name, a different set of goals than we had when defining 
URNs.    Whatever their reasons, without at least some formal agreement 
from the maintainers of the other namespaces to conform to a common 
syntax, trying to align the syntax of URNs with those namespace seems 
like a bad idea.  It has the potential to limit the extensibility of 
both URNs and those other kinds of identifiers.    And I really think 
it's far too soon, and there is far too little experience, to try to 
impose strong constraints on the set of modifiers for identifiers for 
network-accessible resources.

So if persistent identifier scheme xyx has defined "?" to mean one 
thing, I don't think we should consider that an imposition on URNs at all.
We should do what makes the most sense for URNs, and sort out the 
differences at a lower layer.

Keith

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 7 Aug 2014 11:12:24 -0400

> From: [email-masked] (Henry S. Thompson)

>     to construct another URN which identifies a specific sub-part of

Let's also add that it would be desirable to:

(3) Be able to algorithmically distinguish these "derived" URNs from
their "base" URNs.

(4) Algorithmically reverse these transformations, that is, to compute
the "base" URN from the "derived" URN.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 7 Aug 2014 11:15:13 -0400

> thing.  A working group to implement a particular pair of solutions is

Beware that there might be a typographical error involved here.  In
the innermost quote, there is the word "iff".  That means "if and only
if", and in this context, it means "The only way that this can be done
is if we agree that ...".

But it may be a mistake, and the intention was "if".  In that case,
the sentence means "One way that this can be done is if we agree that
...".

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 7 Aug 2014 11:26:14 -0400

> From: Juha Hakala <[email-masked]>

> sending service requests to resolvers.

The overall discussion seems to me to be confusing two issues:

1) Given a URN, there must be a way of obtaining metadata (and other
related information) about the named object.  There must be a way of
providing resolution process with "service parameters".

2) Given a URN, there must be a way of constructing a character string
(which is a URN, or perhaps an "extended URN"), which, when input to
the resolution process, can obtain metadata and provide the resolution
process with service parameters.

Now, (2) -- if we decide to accept it -- is a requirement of *URN
syntax and semantics*, and is within our remit.

If we decide that (1) is sufficient, then we do not need to have (2)
as a requirement, and how to satisfy (1) is not within our remit.

In particular, if we would like to envision resolution services that
are implemented by making HTTP GET requests, there is no particular
reason that URNs have to look exactly like what is sent in the GET
request, and (for example) the fact that using query parts in GET
requests is useful to carry some bit of information does not imply
that that bit of information must be in the URN in a query part.

(Unless we add the requirement: 3) The URN must be enterable directly
into an existing browser and cause the resource to be fetched.)

There are a bunch of service mechanisms for URNs described in the RFCs
mentioned above.  As far as I know, none of them have been widely
implemented.  In regard to URN syntax and semantics, it does not seem
to have been important in determining whether these service mechanisms
are implemented.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 7 Aug 2014 11:28:36 -0400

> the role of fragments in identification.

You speak of "rules of identifier systems" as if they are
pre-existing.  Can you explain the nature of "rules of identifier
systems"?  Can you amplify this into clear requirements on URN syntax
and semantics?

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 7 Aug 2014 11:31:31 -0400

> efficient means for making service requests.

That is an assertion about implementation convenience, not a
requirement.

> Moreover, implementing some other method would make it more
> difficult to make ARK / Handle / URN resolvers interoperable.

Can you state what this interoperability requirement is?

Not knowing much about the subject, I would assume that ARK resolvers,
handle resolvers, and URN resolvers would all have to be communicated
with in different manners.

Dale

---

From: [email-masked]
Date: Thu, 07 Aug 2014 20:34:35 +0300

Hi Dale,

> systems"?  Can you amplify this into clear requirements on URN syntax

These rules certainly exist, but they are always namespace specific.  
There are no written rules which apply to e.g. all the ISO  
identifiers, although you can safely assume that all these identifiers  
are both unique and persistent. That is of course just a beginning. In  
addition to the general principles included in the standard  
publication, there are usually user guides / manuals maintained by the  
international centre responsible of the standard and the user  
community. For instance, the ISSN manual is available here

http://www.issn.org/understanding-the-issn/assignment-rules/issn-manual/

ISBN manual is available in several languages here:

https://www.isbn-international.org/content/isbn-users-manual

There are also loosely managed URN namespaces such as UUID which do  
not have (any) principles concerning what can be identified and by  
whom. But the URN system must accommodate even those traditional  
identifiers which are strictly managed. Allowing substantial changes  
in existing practices would be regarded as extremely disruptive by the  
communities affected. So I can say, for instance, that URN must not  
extend the scope of identifier systems (by for instance enabling ISBN  
assignment to physical fragments of books) and URN also must not allow  
people who are not entitled to do so by the community rules to assign  
ISBNs.

 From my point of view, a persistent problem in URNBIS is that while  
the IETF community is very familiar with e.g. URI syntax, few people  
outside the identifier communities are aware of the implications of  
using these identifiers in the URN context. We have had a fair amount  
of semantic misunderstandings as a result of that. Of course this is  
mainly my fault; I have frequently failed to make my intentions clear  
enough.

Juha

---

From: [email-masked]
Date: Thu, 07 Aug 2014 20:49:18 +0300

Hello,

> is if we agree that ...".

"iff" was intentional. The reason for this is that if fragment and  
query were part of NSS, URN would extend the scope of several existing  
identifier systems in an unacceptable manner (unacceptable from the  
point of view of rules for identifier assignment, as specified in user  
manuals etc).

Of course there can be other methods for passing queries to resolvers.  
DDDS is already in place, but has not been implemented, which is why  
we need to consider an alternative. Some other DNS-based solutions may  
be developed in the future.

Moreover, only a small set of pre-specified queries would be reserved  
for resolution service requests. People who have other ideas on how to  
use queries in the URN context would be welcome to do so, as long as  
they avoid reserved things (for instance, "s=" can be used to indicate  
service specification and "p=" service parameter.

Juha

---

From: [email-masked]
Date: Thu, 07 Aug 2014 21:25:46 +0300

Hello,

Quoting Keith Moore <[email-masked]>:

>> some other method would make it more difficult to make ARK / Handle  
>> / URN resolvers interoperable.
>
> Or perhaps I should rephrase the question: Why is it more important  
> to use URI query syntax to pass parameters to URN resolvers, than it  
> is to be able to use URI query syntax to pass messages to the  
> resources named by those URNs?

These things are not mutually exclusive. We need only a very small  
subset of all possible URN queries for service requests. There will be  
a lot of room for other kind of query usage.

  Because we know from vast experience
> that it's tremendously useful to be able to bundle a URI that  
> identifies a resource with a message that gets passed to that  
> resource and which potentially affects the information returned by  
> that resource.   It's probably not a stretch to estimate that nearly  
> every web server provides access to a few resources that work this  
> way.

OK.

>
> To me it also seems incredibly shortsighted to define query syntax  
> with URNs in such a way as to preclude being able to bundle a  
> message to be passed to the resource, with the URN.   That would  
> essentially be saying that it's more important to optimize URNs to  
> work with fixed/physical media resources than to optimize URNs to  
> work with network-connected resources... which is indeed odd  
> considering that URNs were created primarily for the latter purpose.

It has never been an intention to prevent other query usages; all we  
ask is to be able to use query also for service requests.

>
> Or to put it another way: URI syntax (as defined and in practice)  
> really limits the number of modifiers with which URIs can be  
> bundled, and doesn't leave much room for extensibility.   Do we  
> really want to restrict the use of "?" with URNs in such a way that  
> the only thing that can be done with it is to pass parameters to a  
> resolver?

No, we certainly don't want to do that.

  I
> think I understand why people want to bundle resolver queries with  
> URNs, but I also think that that's about the least compelling use  
> case I can think of for attaching modifiers to a URN.   Certainly it  
> seems less compelling than wanting to narrow the resource being  
> named to a particular facet of that resource like chapter or edition  
> or language or timecode range, and less compelling than wanting to  
> include a message/query to be sent to the resource.   Still, I don't  
> want to say "you cannot bundle a resolver query with a URN".  I am  
> just saying "please, let's define a way to do that, that doesn't  
> prevent other kinds of modifiers to be bundled with URNs".

That has been our intention all the time. That's why we need to  
specify query syntax for each resolution request that can be made.

> compelling use cases in the future.   Simply redefining "?" and "#"  
> to have different meanings than for other URIs, while being  
> consistent with syntax for other URIs, won't leave room for  
> expansion.   I want us to define an extensible syntax for URN  
> modifiers, such that a client can tell which modifiers are resolver  
> queries, which ones are facets that narrow the resource being named,  
> and so forth.   And I want to do it in such a way that doesn't break  
> existing things that understand URIs.

We have to consider carefully which kind of queries can / should be  
specified, and where. There are valid implementation needs which could  
be disruptive in some namespaces / application environments, but OK  
elsewhere.

>>
>> Since query is not part of the NSS, the original URN and the URN  
>> with query identify the same thing (that is, they are lexically  
>> equivalent).
>
> Well, no.   They both contain the same URN, but it's misleading at  
> best to say that the two are equivalent.    You should not, for  
> instance, treat them as equivalent for the purpose of caching the  
> result.   Equivalence is probably not a very useful concept when  
> talking about extended URNs.    You can compare the URNs embedded in  
> them, and that might occasionally be useful.    But comparing two  
> extended URNs in their entirety probably won't be useful for much.

This depends on how we define lexical equivalence. If the criterium is  
that two URNs are equivalent if they identify the same thing, then NSS  
is the only thing we need to consider, and we can ignore fragment and  
query when comparing URNs.

In the current rfc2141bis lexical equivalence has been specified like this.

If we include fragment and query in the comparison, things get very  
complicated. For instance, you can have one identifier which covers  
two different versions (difference being the mime type) of the same  
document. Two URNs which have fragments indicating exactly the same  
location within the identified versions of the document will not look  
identical, but they are lexically equivalent. You may also have URN  
with two different queries which retrieve the same bibliographic  
record from two databases. Again, these URNs look different but are  
lexically equivalent.

I fully agree that equivalence is not a useful concept if we include  
fragment and query in the analysis. We are better off ignoring them.

>> namespace were so liberal as to approve query usage in  
>> identification, "name for something else entirely" would become a  
>> major problem. In my opinion, saying that URI query identifies  
>> something just cannot be right in any context.
>
> reasonable to say that a URN with a query identifies something. It's  
> not reasonable to assume in either case that the binding between the  
> URI and what is identified, is persistent.

It may be reasonable to say that URN with query identifies something  
else than the identified document from the IETF point of view, but I  
repeat, extending the scope of existing identifier systems like this  
is totally unacceptable and also impractical. URN:ISBN can be used to  
identify a book, but URN:ISBN extended with query cannot be used to  
identify a bibliographic record. Of course we could avoid all problems  
by specifying a new namespace for this extended URN, but then there  
would be two other problems: there are already identifiers for  
bibliographic records, and queries, unlike namespace specific strings,  
are not likely to be persistent.

>> I do not think that allowing the use of fragments with URNs  
>> overloads the URI fragment syntax.
>
> The current meaning of fragment syntax is defined by the media type,  
> and fragments are evaluated according to the rules of the media  
> type.  If you are proposing to do it differently for URNs, that's  
> overloading the syntax.

No, I am suggesting that fragment is used with URNs exactly as they  
are used with URIs. No difference whatsover is needed for syntax or  
overall purpose. We only need to say that in the URN context fragment  
does not identify anything, to accommodate the existing identifier  
systems.

Please note that URN + fragment is valid iff the identifier applies to  
single manifestation of a resource only. There will be plenty on  
namespaces where fragments cannot be used, because the identifier does  
not apply to any resources, is not resolvable, or applies to multiple  
resources (files).

>
> Now, having said that, I'll readily admit that HTML fragments are  
> really poorly designed and not terribly useful.   And I haven't seen  
> fragments used frequently with other kinds of media, so I don't know  
> how useful they are with other media types.   But I think it's  
> possible to do a better job than what was done with HTML.
>
> The point is, if we're going to change what fragment syntax means in  
> the context of URNs, it's going to potentially break a lot of  
> software out there that thinks it knows how to interpret "#" in the  
> context of URIs.   We need a really good reason to do this.   At a  
> minimum, we need to redefine fragments in a way that works a lot  
> better than it does with HTML.

I sincerely hope that URNBIS does not need to touch this can of worms ;-).

Juha

>
> One problem with HTML fragments is that because of how they're  
> defined and implemented, they're inherently restricted to the  
> context of a particular "file" or "page".   The client generally has  
> to download the entire "page" before it can search for the specific  
> fragment that was requested.   This works marginally well for  
> relatively small text files, horribly for many other kinds of media,  
> like large video programs.    Another problem with HTML-style  
> fragments is that they're restricted to regions of a document that  
> don't overlap the boundaries of other portions of the document  
> hierarchy.   So while you can have a fragment that only consists of  
> a portion of a paragraph, you can't have a fragment that consists of  
> the end of one paragraph followed by the start of the next.  Nor can  
> you have two fragments that overlap each other unless one is a  
> strict subset of the other.   Nor can a fragment contain sections of  
> multiple files, even though it's quite common to represent a single  
> document as large numbers of HTML files.   And fragment names are  
> portable way to talk about volumes or chapters or sections or pages  
> or timecode ranges, etc.   And there are many other limitations of  
> HTML's way of defining fragments.
>
> So if we're going to redefine how fragments work in the context of  
> URNs, let's do it in a way that makes them a lot more flexible and  
> broadly applicable.   At the very least it should be possible to  
> pass a fragment identifier to a resolver, and for that resolver to  
> be able to say "in order to find the specific fragment you're  
> interested in, you need to download only this one file rather than  
> all of the files associated with the resource".  Or maybe "in order  
> to find the fragment X, pass query parameter Y to the resource". And  
> in the absence of any specific instructions from the resolver,  
> fragment processing should fall back to the current behavior.
>
> Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Aug 2014 14:28:01 -0400

On 08/07/2014 01:34 PM, [email-masked] wrote:
> So I can say, for instance, that URN must not extend the scope of 
> identifier systems (by for instance enabling ISBN assignment to 
> physical fragments of books) and URN also must not allow people who 
> are not entitled to do so by the community rules to assign ISBNs. 
That seems reasonable.   However, if there were a syntax and controlled 
vocabulary that allowed one to refer to, say, a chapter of a resource 
named by a URN, the meaning of that notation as applied to a URN with 
namespace isbn would be relatively unambiguous.   But I think that as a 
practical necessity, even with such a controlled vocabulary, there's 
going to be a need to consult a resolution service to understand how to 
interpret something like a "chapter" relative to a network-accessible 
resource.   So if the resolution service consulted for "isbn" basically 
said "chapter is not a defined term for this resource" or more likely 
"the only vocabulary terms that are supported by this service are x, y, 
and z", I think that would be sufficient.

(And of course, someone using "urn:isbn:1234/chapter-number=3" wouldn't 
be assigning a new ISBN or even a new ISBN URN; they'd be generating an 
extended URN consisting of an ISBN URN and a chapter reference.   Just 
as with a query or a fragment, the facet isn't "part of" the URN.)

Or to put it differently: I think it would be a good idea to define a 
common vocabulary across all URNs to encourage some consistency among 
facet references associated with URNs.   Of course not every facet will 
be applicable to every URN.   "chapter" would rarely apply to a sound 
recording, and a timecode range would rarely apply to a text document.   
But architecturally speaking, those limitations should be presumed to be 
on a per-resource basis, rather than a per-NID basis.   Even if some 
namespaces only assign URNs to certain kinds of media, that's not true 
for all namespaces.    And the information about what facets are 
relevant for a particular resource should be supplied by a resolution 
service, rather than being wired into applications that process URNs.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Aug 2014 15:20:02 -0400

> a lot of room for other kind of query usage.

I'm not sure if this is what you have in mind or not, but: I really 
don't like the idea of trying to distinguish the two kinds of queries 
based on reserving certain keywords for resolution service requests.  I 
think it will be very difficult to define all of the keywords that will 
ever be needed, and also difficult to avoid collisions with keywords 
used by existing resources.

>> with URNs in such a way as to preclude being able to bundle a message 
>> to be passed to the resource, with the URN.   That would essentially 
>> be saying that it's more important to optimize URNs to work with 
>> fixed/physical media resources than to optimize URNs to work with 
>> network-connected resources... which is indeed odd considering that 
>> URNs were created primarily for the latter purpose.
>

I think it's difficult to do the latter, while using query syntax, 
without preventing the former.   That's why I've been suggesting an 
alternate syntax, not using "?", for parameters to be passed to the 
resolver.

Having said that, it occurs to me that we could have the resolution 
service tell the client how to process queries.   It could say "for URN 
urn:foo:bar, parameters a, b, and c apply to the resolution service, and 
parameters c, d, and e apply to the resource" (overlap in the example is 
intentional).   In the absence of such a statement, any query parameter 
for that URN would apply to the resource.   But that still makes it 
difficult to standardize query parameters for resolution services 
without introducing the potential for a conflict with parameters used by 
existing resources.
>
>> I think I understand why people want to bundle resolver queries with 
>> seems less compelling than wanting to narrow the resource being named 
>> to a particular facet of that resource like chapter or edition or 
>> language or timecode range, and less compelling than wanting to 

I don't think we can reliably anticipate every resolution parameter that 
we're going to need.   And I don't think we can use "normal" vocabulary 
for resolution parameters without colliding with query vocabulary 
already used for some set of resources.

We could pick some syntax convention for resolution parameters that we 
believed was unlikely to conflict with existing query usage by 
resources.  For example, we could insist that all resolution service 
parameters have names beginning with "@".  So one could specify 
urn:foo:bar?@volume-number=2&@chapter-number=24 or urn:foo:bar?@request=urc

(if it's not legal to use "@" there without percent-encoding it, pick a 
different character that is legal)

For any legal character we pick, I expect that there's some web site 
that is using query parameters that begin with that character.   But 
maybe that's not so bad, as long as such collisions are sufficiently 
rare.   Most of those web sites will probably never have URNs assigned 
to them anyway.

Question: which is better, and why?

a) urn:foo:bar?@parameter1=value&@parameter2=value&parameter3=value

or

b) urn:foo:bar/parameter1=value/parameter2=value?parameter3=value

(in both cases, parameter1 and parameter2 are interpreted by the 
resolution service, and parameter3 is interpreted by the resource)

> be disruptive in some namespaces / application environments, but OK 

Once we define these queries I don't think we can stop people from using 
them in contexts for which they make no sense, and/or for which the 
namespace thinks the query parameter isn't appropriate. The best we can 
do, I think, is have the resolution service indicate when that query 
parameter is an error, or is irrelevant and to be ignored, etc.  That 
way, at least, attempts to combine queries with URNs for which the 
combination makes no sense, or is undefined, will fail when used.   But 
I suspect there will be pressure to make some such queries work on a 
widespread basis even if some of the namespaces wish to discourage them.

> query when comparing URNs.

Right.   But two extended URNs that contain the same URNs but different 
modifiers do not necessarily refer to the same resource, even if they 
are defined relative to the same resource.

If there's a need to compare two extended URNs for equivalence I think 
it has to take several things into account:

- equivalence of base URN
- if the modifiers can appear in different orders and order is 
irrelevant, sort the modifiers before comparing
- perhaps some of those modifiers don't actually change the resource but 
are used for other purposes, so those should be ignored for 
comparison.   and you have to query the resolution service to find out 
which modifiers are irrelevant for comparison.
etc.

> fragment and query in the analysis. We are better off ignoring them.

At least, as you say, it's very complicated to try to make it useful.

> is totally unacceptable and also impractical.

Yes, but we're not "extending the scope of existing identifier systems", 
because these modifiers are not part of those identifiers.   We're 
defining ways of bundling together identifiers and modifiers into a new 
kind of URI that just happens to begin with a URN.   An "extended URN" 
is closer to being a way of expressing a kind of query than a resource 
name.

You might say "but we don't want to define any modifiers that change the 
scope of identifiers".   I don't think that will fly.   There are far 
more valid and practical reasons that people want to do that, than there 
are reasons that people need a compact way to express things like "query 
the resolution service for URN x using parameters a, b, and c".   If we 
build a language that allows people to bundle queries with URNs, it's 
going to be used for all kinds of different things that we didn't 
anticipate.

If there's one thing that we understand about the Internet, it's that we 
can't control how people will use the protocols that we create.

> URN:ISBN can be used to identify a book, but URN:ISBN extended with 
> query cannot be used to identify a bibliographic record.

Of course it can.  And it will.   How could we stop it from happening?

Keith

---

From: Juha Hakala <[email-masked]>
Date: Fri, 08 Aug 2014 08:22:17 +0300

Hi,

On 7.8.2014 22:20, Keith Moore wrote:

> based on reserving certain keywords for resolution service requests.  
> I think it will be very difficult to define all of the keywords that 
> will ever be needed, and also difficult to avoid collisions with 
> keywords used by existing resources.

We shall need keywords to define services, and 0-n parameters per service.

RFC 2483 contains the initial set of services. 9 keywords are needed to 
cover them, from s=I2L to s=I2I. Parameters are more tricky; for 
instance URI to URC may need a lot of them (about 20 to start with) due 
to profileration of metadata formats. There is also a need to specify a 
few new services. But all in all, defining the keywords needed for 
current & currently foreseen services is manageable.

The query syntax we've suggested (e.g. ?s=URC&p=MARC21) may already be 
used somewhere, but certainly not in the URN context.

> service tell the client how to process queries.   It could say "for 
> URN urn:foo:bar, parameters a, b, and c apply to the resolution 
> service, and parameters c, d, and e apply to the resource" (overlap in 
> the example is intentional).   In the absence of such a statement, any 
> query parameter for that URN would apply to the resource.   But that 
> still makes it difficult to standardize query parameters for 
> resolution services without introducing the potential for a conflict 
> with parameters used by existing resources.

When resolvers get smarter, we shall need a new service which will 
enable a client to ask from a resolver which services and service 
parameters it supports. Then the client would know what kind of 
resolution service requests can be met by the resolver. It should also 
be possible to harvest this information from servers into a data store 
which clients can use.

Similar service, called Explain, is included in search protocols Z39.50 
and SRU which the library community uses.

>
> I don't think we can reliably anticipate every resolution parameter 
> that we're going to need.   And I don't think we can use "normal" 
> vocabulary for resolution parameters without colliding with query 
> vocabulary already used for some set of resources.

This difficulty in anticipating which services and service parameters 
will be required is the main reason why we need a flexible mechanism for 
adding them. Revising RFC 2483 each time somebody needs to support e.g. 
a new metadata format for URI to URC is not viable.

> urn:foo:bar?@volume-number=2&@chapter-number=24 or 

IMO we have already specified a syntax convention which is unlikely 
enough to conflict with existing usage. And the probability of such 
collisions in existing URN resolvers is 0.

> Yes, but we're not "extending the scope of existing identifier 
> systems", because these modifiers are not part of those identifiers.   
> We're defining ways of bundling together identifiers and modifiers 
> into a new kind of URI that just happens to begin with a URN.   An 
> "extended URN" is closer to being a way of expressing a kind of query 
> than a resource name.
>
> You might say "but we don't want to define any modifiers that change 
> the scope of identifiers".   I don't think that will fly. There are 
> far more valid and practical reasons that people want to do that, than 
> there are reasons that people need a compact way to express things 
> like "query the resolution service for URN x using parameters a, b, 
> and c".   If we build a language that allows people to bundle queries 
> with URNs, it's going to be used for all kinds of different things 
> that we didn't anticipate.

This is fine with me. What I am saying is that:

1. Many identifier communities have strict rules which specify what can 
be identified and by whom.
2. These rules apply to the namespace specific strings and only to them.
3. If we say that query and fragment are part of NSS, there is a 
problem. If they are not part of the NSS - that is, they do not identify 
anything - fine.

And possibly:

4. Some namespaces may want to implement identifier assignment policies 
which allow the usage of query and / or fragment for identification. If 
so, they must be encoded so that they are part of the NSS. 
Alternatively, we may say that using queries and fragments for 
identification is forbidden in all namespaces, or we may be silent about 
this.

>
> If there's one thing that we understand about the Internet, it's that 
> we can't control how people will use the protocols that we create.
>

Based on what I say above, it is fine if people use 
URN:ISBN:<ISBN>?s=URC to retrieve metadata about a book. There is no 
need to prevent that. They may also use their own query syntax to 
retrieve the same metadata.

But it is not OK to build a system where these extended URN:ISBNs are 
used as identifiers for bibliographic records retrieved. Of course, URN 
like URN:XXX:<ISBN?s=URC> (in a properly encoded form) would not violate 
ISBN assignment rules, but I would still not recommend using URNs like 
this since there is no 1:1 relation between bibliographic records and ISBNs.

One reason we have problems understanding each other is that "to 
identify" means different things not only to us, but also in different 
URN namespaces. In the ISBN namespace identification is a managed 
process and according to the well established rules it would be an 
abomination to give an ISBN + query to bibliographic record. Some other 
namespaces with more liberal identifier systems might not have problems 
with such a practice.

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: Keith Moore <[email-masked]>
Date: Fri, 08 Aug 2014 01:56:48 -0400

On 08/08/2014 01:22 AM, Juha Hakala wrote:
> RFC 2483 contains the initial set of services. 9 keywords are needed 
> to cover them, from s=I2L to s=I2I. Parameters are more tricky; for 
> instance URI to URC may need a lot of them (about 20 to start with) 
> due to profileration of metadata formats. There is also a need to 
> specify a few new services. But all in all, defining the keywords 
> needed for current & currently foreseen services is manageable.

RFC 2483 is only an Experimental document, and for good reasons - it's 
not very well thought out, and it's very incomplete.   But if it serves 
(or has served) as a starting point for experimentation and additional 
discussion, that's a good thing of course.

> used somewhere, but certainly not in the URN context.

It doesn't matter whether it's used in the URN context.   We want to be 
able to use URNs to name network-accessible resources, and there are 
many, many network-accessible resources for which "s" and "p" are valid 
query parameter names.

>> service, and parameters c, d, and e apply to the resource" (overlap 
>> in the example is intentional).   In the absence of such a statement, 
>> any query parameter for that URN would apply to the resource.   But 
>> that still makes it difficult to standardize query parameters for 

There's no reason that I can see why resolvers can't "get smarter" 
rather quickly.   Certainly it makes more sense for resolvers to "get 
smarter" than to cripple the ways that URNs can be used.

>
> Similar service, called Explain, is included in search protocols 
> Z39.50 and SRU which the library community uses.
>
>
>>
> will be required is the main reason why we need a flexible mechanism 
> for adding them. Revising RFC 2483 each time somebody needs to support 
> e.g. a new metadata format for URI to URC is not viable.

The usual solution to such issues is an IANA registry.

>
>>
>> We could pick some syntax convention for resolution parameters that 
>> we believed was unlikely to conflict with existing query usage by 

Strongly disagree that the RFC 2483 convention is unlikely to conflict 
with existing usage.   Collisions within existing URN resolvers is not 
the issue; the issue is conflicting with the ability to use URNs to name 
network-accessible resources that accept queries.

>> systems", because these modifiers are not part of those 
>> identifiers.   We're defining ways of bundling together identifiers 
>> and modifiers into a new kind of URI that just happens to begin with 
>> a URN.   An "extended URN" is closer to being a way of expressing a 
>> kind of query than a resource name.
>>
>> far more valid and practical reasons that people want to do that, 
>> than there are reasons that people need a compact way to express 
>> things like "query the resolution service for URN x using parameters 
>> a, b, and c".   If we build a language that allows people to bundle 
>> queries with URNs, it's going to be used for all kinds of different 
>> things that we didn't anticipate.
>
> 1. Many identifier communities have strict rules which specify what 
> can be identified and by whom.
> problem. If they are not part of the NSS - that is, they do not 
> identify anything - fine.

Yes, I think that's where we have to draw the line.   Modifiers (I don't 
think query and fragment are sufficient) are not part of the NSS.

>
> And possibly:
>
> 4. Some namespaces may want to implement identifier assignment 
> policies which allow the usage of query and / or fragment for 
> identification. If so, they must be encoded so that they are part of 
> the NSS. Alternatively, we may say that using queries and fragments 
> for identification is forbidden in all namespaces, or we may be silent 
> about this.

I don't think encoding them in the NSS is a good idea; I think it will 
not work well in practice because there are too many situations where 
ordinary users will want to restrict the scope of a reference that 
includes a URN, and those ordinary users will want to construct the 
extended URNs that do that.

Furthermore I don't think that whether particular modifiers apply to a 
URN should be an attribute of the namespace, but rather, an attribute of 
the resource.   Or more precisely: the namespace can set a policy if it 
likes, but clients shouldn't assume that such characteristics are 
namespace-specific; they should consult the resolution service to learn 
which modifiers are applicable for that particular URN.   If the 
resolution service for a particular namespace always returns the same 
answers to such queries for all URNs coined from that namespace, that's 
fine.

> used as identifiers for bibliographic records retrieved.

But people will do exactly that, no matter what we say, and they'll want 
to treat those extended URNs as identifiers.   Saying "you can construct 
these things but don't treat them as identifiers" is too much subtlety 
to expect users to understand.

(the same is likely to be true for any combination of URN + modifier, no 
matter what kind of modifier)

>
> Of course, URN like URN:XXX:<ISBN?s=URC> (in a properly encoded form) 
> would not violate ISBN assignment rules, but I would still not 
> recommend using URNs like this since there is no 1:1 relation between 
> bibliographic records and ISBNs.

I agree that this is not a good idea.

> abomination to give an ISBN + query to bibliographic record. Some 
> other namespaces with more liberal identifier systems might not have 
> problems with such a practice.

Yes it's tricky, for this reason, and for many other reasons.   But in 
defining URN standards we need to do so in a way that's independent of 
particular namespace characteristics.   It's a balancing act - to try to 
respect and accommodate the needs of various namespaces on one hand, 
without impairing URN utility for other less restrictive namespaces or 
making client implementations too complex on the other hand.

Keith

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 8 Aug 2014 18:11:21 -0400

[For some reason, the messages with the subject "Rules for identifier
systems" have been coming to me directly, but not via the URN mailing
list, despite being CC'ed to the mailing list.  I'm sending this to
the mailing list only, on the assumption that this problem will not
recur.]

> From: [email-masked]

> [...] But the URN system must accommodate even those traditional  
> communities affected. [...]

If I may complain a moment:  You've said things like this several
times in the past.  And what you say makes sense.  The problem is that
it is not "actionable", because there is no way for anyone in the
working group (except possibly yourself) to determine what would
require a "substantial change in existing practices".

What we need (from your or somebody) is a clear statement:  "If the
URN syntax and semantics follows rules X, Y, and Z, then we can are
assured that it will not interfere with the existing practices of
*any* of the identifier systems which are to be embedded as URN
namespaces."

Now currently, it seems to me that there are two requirements that
have to be observed:

1) An identifier consists of a sequence of characters, the syntax of
which is defined by the identifier system (not the URN syntax).
Therefore, there must be a way of encoding an *arbitrary* character
string as the namespace-specific string of a URN.  Conversely, looking
at a URN, there must be an algorithmic way of extracting its
namespace-specific string as a sequence of (unencoded) characters, so
that that string can be considered as an identifier within the
identifier system.  (It would be convenient if the extraction
algorithm is namespace-independent, but it appears to me that is not
strictly necessary.)

(Note that since we are revising the RFC, exactly what part of a URN
is the "namespace-specific string" can be redefined if we want to.)

2) If we devise mechanisms to (a) designate parts of the identified
resource, (b) provide instructions as to which resolver to use or in
what manner, or (c) to specify information that is "related" to the
identified resource, and ---> if this mechanism involves modifying the
URN to produce a "decorated URN" character string (and that has not at
this point been agreed upon) <--- , then it must be possible to
algorithmicly remove the "decoration" to produce the "base URN", and
the "decoration" must not be considered part of the namespace-specific
string (that is, the "identifier" proper).  That is, "decorating" a
URN will fundamentally change its identifier part.  (Whether we
consider "decorated URNs" to be "URNs" in the strict sense of the word
is a matter of terminology to be settled later in whatever way makes
discussion most convenient.)

At this point, I think that those two requirements will satisfy all
the needs that you've articulated (and that I have understood).

Dale

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Aug 2014 06:25:39 -0400

> is the "namespace-specific string" can be redefined if we want to.)
Provided, of course, that we don't change the meaning of existing URNs 
that conform to RFC 2141 syntax.

(Actually, I can't imagine that we would redefine 
namespace-specific-string, even if we were to allow "decorations" to 
follow it.)

Keith