Subject: Re: [urn] urn:ietf:rfc

From: "Svensson, Lars" <[email-masked]>
Date: Tue, 3 Jun 2014 10:38:15 +0000

All,

(working my way through those threads...)

> > > But once we get to ISBN and ISSN, the meaning is much detached
> > > from resolution.  In particular, there are assumed to be many
> > > different ways of resolving the identifier (for various
> > > purposes), and no one of them is expected to yield "the"
> > > meaning.
> >
> > And here is where I get confused about where you are going
> > because, e.g., an ISBN, once assigned, very much identifies an
> > object.
> 
> Aye, but let's look at it in a couple of different ways.
> 
> One way to look at it is from the network engineering point of view.
> An ISBN identifies "a book", but that isn't a network-accessible
> resource, and so it's pretty much irrelevant.

Depends on: eBooks can and do have ISBNs, too, and they are very much network accessible, e. g. [1].

>  If you're trying to get
> any information via the internet about the book, what you're really
> getting is various network-accessible resources that are only
> sociologically connected to "the book".  Many of these are considered
> "metadata" (cataloging information, current price on the used book
> market, etc.) but some might be seen as semantically overlapping "the
> book", such as a recording of the book's text or page images from the
> book.

If it is a book at all and not e. g. a puzzle [2].
> 
> Our concept that the ISBN identifies "a book" diverges from the
> reality that anything you can do with the ISBN on the internet is at
> best a small subset of the information connected to "the book".  In
> this regard, an ISBN URI is much more abstracted than an HTTP URI.

No, not really. [3] is an identifier for TimBL, and on the internet you cannot really *do* very much with him by just using that identifier. It is always a matter of which services you want to offer.

> To add a layer of complexity, the "book" object that an ISBN
> identifies is an abstraction.  I mean, there is a *book* on my desk at
> this moment, but the ISBN printed on that book doesn't really identify
> that object -- the ISBN identifies the entire set of existing and
> potential books that are "from the same edition" (or whatever the
> proper technical term is). And this concept of an object is even
> farther from the network engineering, because it isn't even a
> physically describable thing.  (Of course, the library/publisher
> people understand this, but it's an example that are hierarchies of
> concepts that we often blithely lump together as "objects", and then
> expect them to behave in generally similar ways.)

Yes, this is seen as one of the problems of rfc 3986, too: it tries to lump things together that had evolved in totally different directions. Nonetheless, I think there are other concepts in network engineering that are not physically describable either, so that should not be a major obstacle.

[1] cf. http://d-nb.info/1031739254 which is an identifier for the eBook "Der Weg zur optimalen Kühlung des PCs" with ISBN 978-394-30185-7-8 and urn urn:nbn:de:101:1-2013022715846 immediately accessible through http://nbn-resolving.de/urn:nbn:de:101:1-2013022715846
[2] https://www.qbd.com.au/product/9781743529805
[3] http://d-nb.info/gnd/121649091

Lars

---

From: John C Klensin <[email-masked]>
Date: Sat, 14 Jun 2014 04:39:22 -0400

--On Tuesday, June 03, 2014 10:38 +0000 "Svensson, Lars"
<[email-masked]> wrote:

>...
>> Our concept that the ISBN identifies "a book" diverges from
>> the reality that anything you can do with the ISBN on the
>> internet is at best a small subset of the information
>> connected to "the book".  In this regard, an ISBN URI is much
>> more abstracted than an HTTP URI.
> 
> No, not really. [3] is an identifier for TimBL, and on the
> internet you cannot really *do* very much with him by just
> using that identifier. It is always a matter of which services
> you want to offer.
>...

The one thing I would add to the above is that parts of the URN
discussion could be seen as about adding mechanisms for service
requests to the overall URN string.  If "what services you want
to offer" is the right vocabulary (I, at least, found it very
helpful), then "service request" may be much closer to what is
needed then such apparently-specific types of service requests
as "queries" or "fragments".

That may then take us back to discussions of many months ago as
to whether one can or should use the query notion and syntax to
hide or encapsulate what we can now call service requests with
very different characteristics.  The answer appears to be "yes,
but only if one is willing to resort to syntax tricks or other
mechanisms to deal with services that don't fit in the same 'who
does what to whom (or which objects or date' frameworks".

See the note I just posted titled 'Tuning the "URNs are not
URIs" spec'.

best,
   john

---

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 16 Jun 2014 08:18:30 +0000

John,

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]]
> Sent: Saturday, June 14, 2014 10:39 AM
> To: Svensson, Lars; Dale R. Worley
> Cc: [email-masked]
> Subject: RE: [urn] urn:ietf:rfc
> 
> 
> 

Yes, "service request" sounds good to me.

> does what to whom (or which objects or date' frameworks".

Perhaps this is where the tension lies: Who performs the service? In the URN scenario we differ between the identifier (including the identified resource) and the resolution service. My gut feeling is that we need to be more explicit about if the service is performed by the identified resource or by the resolution service. Is there consensus on that?

> See the note I just posted titled 'Tuning the "URNs are not

I need to think a bit about that and shall come back later.

Best,

Lars

---

From: John C Klensin <[email-masked]>
Date: Mon, 16 Jun 2014 08:41:41 -0400

--On Monday, June 16, 2014 08:18 +0000 "Svensson, Lars"
<[email-masked]> wrote:

>...
>> That may then take us back to discussions of many months ago
>> as to whether one can or should use the query notion and
>> syntax to hide or encapsulate what we can now call service
>> requests with very different characteristics.  The answer
>> appears to be "yes, but only if one is willing to resort to
>> syntax tricks or other mechanisms to deal with services that
>> don't fit in the same 'who does what to whom (or which
>> objects or date' frameworks".
> 
> Perhaps this is where the tension lies: Who performs the
> service? In the URN scenario we differ between the identifier
> (including the identified resource) and the resolution
> service. My gut feeling is that we need to be more explicit
> about if the service is performed by the identified resource
> or by the resolution service. Is there consensus on that?

Certainly it is at least part of the tension, but, to make
things a little more complicated, I'm not sure about the
dichotomy between "performed by the identified resource" and
"performed by the resolution service", perhaps partially because
we may be hand waving a bit when we say "resolution service".

I think that earlier comments on the list suggest that the
resolution service (if any) associated with a particular URN is
bound to the NID in its definition, not to URNs generally
(people should check 2141bis to be sure it is clear enough about
that).  But, if "resolution service" is NID-dependent, and given
the number of different flavors of data, metadate, and
representations of objects, I don't see any reason to prohibit
registering an NID whose definition says "for information or
answers of type X, go here; for type Y, go there; and for type
Z, go to this third place" and where  "go" would include some
combination of method, location, and information for applying
them to each other.  Put differently, there is nothing
intrinsically special (or per-NID-unique) about a "resolution
service" -- it is just a direct or indirect mechanism for
obtaining data, metadata, objects, or other information.

If that is the case, then it should be possible for the
URN-string to be explicit about the ways in which, and target to
which, service requests are to be addressed.

> I need to think a bit about that and shall come back later.

I look forward to your comments.
thanks,
    john

---

From: Larry Masinter <[email-masked]>
Date: Tue, 17 Jun 2014 05:47:34 +0000

> There are three ways to get from a URN to one of more resolution
> services

There are as many ways as you want but none are context-independently authoritative.
The only authority for urn:dodo:47 is to look up 'dodo' in the IANA registry of URN names, and to ask the authority listed "what does urn:dodo:47 mean".

All of the other resolution means are temporary expedients, whose behavior and success or failure do not change the meaning.

If the dodo authority moves or changes then the IANA registry will need to be updated.

Obtaining an authoritative result cannot be generically automated, because URN namespaces aren't constrained to offer resolution at all.

A level of indirection doesn't help.

I'm not sure why anyone is bothering with trying to build a standard resolution service when many namespaces don't offer explicit lookup services.

Larry

> Now that raises all of the issues a few of us have been
> discussing.   The URN itself provides information: Dodo 32 is
> presumably a different dodo than Dodo 47.   But one can want to
> locate or obtain Dodo 32, one can want information about it,
> such as its weight or state of health (probably pretty
> consistent for dodos), and so on and a way is needed to talk
> about that different stuff.  More important, if the Dodo
> Registry were, say, at Oxford University, one might want some
> level of indirection in case Oxford decided to transfer the
> registry elsewhere or to close its institutional doors (this is
> one place where the difference between tens of years and tens of
> centuries becomes important).  Our typical way to way to deal
> with that would be to build the constructed URL template as
> Method://international-dodo-registry.org/?dodo-number=32> but
> suppose one's concerns about permanence _for the particular NID_
> was such that you wouldn't want to trust in the continued
> existence of the DNS or that of the ORG TLD?  That is the job
> URN.ARPA was intended to serve, so that dodo.urn.arpa would
> provide a pointer to where the template information was at any
> given time and/or appropriate DDDS material.  That would work
> well for concerns about ORG, but not for concerns about the ARPA
> TLD or the DNS.  For the latter, one would want to abstract
> URN.ARPA too, such that there was a single, URN-specific (not
> NID-specific) definition of where to look for the information
> that is now (optionally) stored at <nid>.urn.arpa.  If the DNS
> imploded, that document could be updated with the new "how to
> find the tree" information and appropriate chronology retained.
>
> This is obviously turtles all the way down and getting the right
> stopping rules requires fairly serious thought.  But, if one
> wants to think about "permanence", one has to do that work...

I admit that I'm happy to merely help define the URN syntax, not the 
resolution rules.

> and then the definers of each NID decide how permanent it needs
> to be in terms of levels of abstraction and indirection such at
> those outlined above.

Yes, that does seem to be a helpful exercise for those who are defining 
NIDs. Do we perhaps need some text along these lines in 3406bis?

Peter

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

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 17 Jun 2014 16:36:32 -0400

> From: John C Klensin <[email-masked]>

> that).

It's clear enough in practice that the resolution service(s) that can
be used in regard to a URN -- or at least, the "well-known" resolution
service(s) -- are determined only by the NID defintion; there is no
generic resolution service that applies uniformly to all URNs.  I
think that I've detected traces of an earlier conception that there
will be a well-known resolution service that applies consistently to
all URNs, but that concept seems to be so obsolete now that nobody has
ever confirmed my suspicions.

> But, if "resolution service" is NID-dependent, and given

All this makes sense to me.

Dale

---

From: Juha Hakala <[email-masked]>
Date: Wed, 18 Jun 2014 11:17:50 +0300

Hello,

On 17.6.2014 23:36, Dale R. Worley wrote:
> generic resolution service that applies uniformly to all URNs.
If the identifier is "dumb", then by definition there can only be one 
URN resolver / resolution service for this namespace (of course, the 
resolver may be mirrored so that there are several physical instances of 
it). The resolver may provide 1-n resolution services, which may change 
over time. ISSN is an example of "dumb" identifier; it is not possible 
to tell where and when the periodical was published just by looking at 
the ISSN string.

If the identifier provided "hints" which help at locating the resolver, 
there may be 1-n resolvers. NBN may have, in theory, unlimited number of 
resolvers. Each country using URN:NBNs typically has at least one, and 
there may be more. On the other hand, it is possible to create a cascade 
of URN:NBN resolvers by copying the URN - URL mapping tables from local 
to national and further to international URN:NBN resolvers.

The URN resolver the National Library of Finland built is "optimized" 
for NBNs. The program that deals with URN "local things" is very short 
and compact, but the program which deals with resolver decentralization 
is more complex.

>   I

Given the number of URN namespaces registered, URNs assigned and URN 
resolvers built, it is not practical to try create a global URN resolver 
which harvests all URN - URL mappings from all resolvers out there. But 
there are definitely a lot of opportunities for namespace specific or 
geographical cooperation.
>> obtaining data, metadata, objects, or other information.

This kind of rich functionality is exactly what the library community 
intends to achieve with query.

But instead of specifying all the required functionality in NID 
registration request, it is better to have RFC 2483bis which specifies a 
mechanism for registering URN resolution services and parameters related 
to them.  For instance, there is already URI to URC service to retrieve 
metadata about resource, but it must also be possible to specify the 
format in which the metadata is to be retrieved. Since new metadata 
formats (and revised versions of existing ones) appear frequently, 
trying to list all these formats in an RFC is too slow a method; an IANA 
registry is needed. NID registrations could then refer to the registry 
when describing the intended services.

So, when a user wants Dublin Core metadata about the resource, the 
resolver should know that a) appropriate protocol is SRU and b) since 
the ISBN is for a Finnish book, the correct place to pass the SRU search 
request to is the SRU server of the national union catalogue.

Converting the URN:ISBN with query requiring metadata about the 
identified resource into SRU ISBN search request is not complicated, but 
the resolver must "know" how to do it.  At present the URN - URL mapping 
tables maintained in resolvers are simple, but when more resolution 
services become available, resolvers must become more "intelligent". In 
order to keep things manageable, resolution services supported by 
resolvers must be standard-based, which will (usually) be the case.

> All this makes sense to me.
And to me too (I think).

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: [email-masked] (Dale R. Worley)
Date: Wed, 18 Jun 2014 14:15:06 -0400

I agree with the bulk of these messages, but there are a few points
which I think need modification.

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

> URN resolver / resolution service for this namespace

There can only be one resolution service that is designed as
"authoritative" by the NID registration, but clearly various
administrators can create multiple resolution services which map the
same identifiers.  It would probably be difficult to ensure that any
un-authoritative resolution service contained information that was
complete.  But if an authoritative resolution service had incentives
to not include information that its users want, I can see that users
might support the creation of an alternative resolution service that
would include additional information.

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

> In practice, two major changes are needed: revised URN syntax should 
> allow the use of fragment and query.

I agree that these would be desirable.  I expect that very little
running code would fail if URN with fragments and queries were used.

> The use of URI fragment to indicate locations within identified 
> resources enables creation of URN-based citations instead of URL-based 
> ones. But in order to avoid breaking the assignment rules of traditional 
> standard identifiers, RFC2141bis must make it clear that the fragment is 
> not part of the namespace specific string (that is, from URN point of 
> view, it does not identify anything).

The limitation on the semantics of <fragment> in RFC 3986 is that its
significance is defined only by the media type of the retrieved
resource, independently of the URI that it is attached to.  I don't
know if that is a problem for URN-based citations; naively it seems to
me to not be a problem.  But of course, if it is a problem, it may be
worth updating RFC 3986 to eliminate that rule.

> There is definitely also a need to use URI query for passing resolution 
> related parameters to URN resolvers. URN resolvers currently in use are 
> dumb; of all the resolution services specified in RFC 2483 they usually 
> support by default only URN - URL mapping (to a single URL only). This 
> is insufficient, since users may not want the document itself. Instead 
> they may be interested in descriptive metadata about the resource, or 
> other versions of the resource (work), etc.

> I have tried to make it clear that for instance library community needs 
> additional functionality which can be provided by query and fragment.

Strictly speaking, "additional functionality which can be provided by
query and fragment" doesn't *need* to be provided by <query> and
<fragment>.  (Within some namespace,) two URN characters could be
reserved to demarcate the <URN-query> and <URN-fragment> within a URN
which conforms to the current syntax.  But that would be poor design,
given that there is unlikely to be a problem if the syntax was
expanded to allow URNs to have <query> and <fragment> parts.

> Technically, DOIs (or Handles or ARKs) can be expressed as URNs, and 
> vice versa. But there is no added value whatsoever if the URN is 
> resolved in the same way as the DOI.

There is added value, in that if a DOI can be expressed as a URN, it
can be placed in a location where the context demands a URI.

Dale

---

From: Juha Hakala <[email-masked]>
Date: Thu, 19 Jun 2014 10:59:05 +0300

Hello,

On 18.6.2014 21:15, Dale R. Worley wrote:
>> From: Juha Hakala<[email-masked]>
>>
>
Fragments are ignored when URNs are resolved so they should cause no 
problems whatsoever.

When a URN resolver encounters a query service request / request related 
parameter it does not support, there are several options. In increasing 
order of preference, the resolver may:

- ignore the query completely (which, I think, is what the HTTP servers 
often do)
- inform the user that the resolution service requested is not supported 
(and, perhaps, send a list of supported ones)
- inform the user that the resolution service requested is supported, 
but not the parameter (for instance, the resolver may support URI to 
URC, but not the metadata format the user asked for)

 From the URN resolver application development point of view, supporting 
rich set of resolution services will be an interesting challenge. 
Sometimes it will be easy to add new services, but that will not always 
be the case. For instance, if a user wants metadata about the identified 
resource, it is easy to map the URN into a URL search request, if the 
target system supports SRU (http://www.loc.gov/standards/sru/) or some 
other well known industry standard. But if the target system is 
proprietary, a technique known as screen scraping must be used. The idea 
is to emulate a typical end user session. Unfortunately the code needed 
tends to be complex and it may break down whenever the GUI of the target 
system is modified.

> expanded to allow URNs to have <query> and <fragment> parts.

Having to specify query and fragment separately for each NID would be 
cumbersome to the extreme. Also, if any Unicode character can be used in 
the identifier itself (as in Handles, for instance) it is not possible 
to reserve some characters to this kind of special usage.
> can be placed in a location where the context demands a URI.

Like URNs, DOIs are usually expressed as URIs, with the address of the 
resolver / proxy included.

URN resolvers would not be able to cope with DOIs. For instance, query 
usage is already possible, but it has a specific meaning. For instance,

http://doi.org/10.1000/demo_DOI

and

http://doi.org/10.1000/demo_DOI?index=3

are both actionable, but they resolve to different documents. Handle 
record may contain multiple URLs with different index values. The latter 
DOI resolves to the URL with index value 3.

DOI Handbook says about resolution 
(http://www.doi.org/doi_handbook/3_Resolution.html) that:

> Increasing numbers of DOI names include data in addition to the single 
> default URL. This is sometimes referenced as multiple resolution. 
> These added values are intended for use by more advanced applications 
> which have the ability to take advantage of multiple pieces of data, 
> e.g., the location of enhanced metadata or related documents. 

DOI and ARK systems are already developing ways of using query in their 
own, non-interoperable ways to pass resolution related guidelines to 
resolvers. If IETF can a) agree that query can officially be used for 
this purpose, and b) provide a means, such as IANA registry, for 
registering resolution services and service related parameters, the 
groups developing persistent identifiers may still be able to avoid 
re-inventing too many wheels.

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 19 Jun 2014 10:57:58 -0400

> Fragments are ignored when URNs are resolved so they should cause no 

Strictly speaking, current code to validate URIs could check to see if
the scheme is "urn", and if so, verify that no "#" is present, as the
current definition does not allow fragments for URNs.  But in
practice, I don't expect any code to do this.

> Also, if any Unicode character can be used in 

It's quite easy to reserve characters:  If the special character
"represents itself", that is, is in the underlying Handle identifier,
it must be represented in the URN as a %-escape.  If the special
character is used with the special meaning, it must be written
explicitly as "#" or "?".  This is done in numerous places in URIs
already.

> resolver / proxy included.

In my experience, what DOIs I've seen are usually represented directly
as DOIs.  So DOIs are gaining some currency as identifiers themselves.

> re-inventing too many wheels.

It sounds to me like more IETF work is needed than just that:  We want
to specify what the contents of the query component are and how they
are to be interpreted and used.  There will need to be a registry for
parameters (sub-values within query), but there will need to be more
extensive definitions of semantics and procedures if there is to be
any uniformity of resolution services.

Dale

---

From: Juha Hakala <[email-masked]>
Date: Mon, 23 Jun 2014 10:21:16 +0300

Hello,

> practice, I don't expect any code to do this.

Clients such as web browsers should not even send URI fragments to 
servers such as URN resolvers. Since fragment has zero impact on how the 
URN is resolved, disallowing fragments from URNs on the client side 
would not make much sense.

We have discussed earlier on this list about the applicability of 
fragments in the URN context. If and only if a URN identifies a single 
digital manifestation of a resource (such as a PDF file) users can apply 
URI fragment any time after the resource has been identified and the 
identifier has been made actionable, provided that the MIME type of that 
file format supports the use of fragment. In such a case it is likely 
that the URN + fragment will be more persistent than URL + fragment.

> explicitly as "#" or "?".  This is done in numerous places in URIs

OK. For the time being, bibliographic identifier standards do not have 
annexes explaining how to make them actionable in the Internet. If and 
when this is done, it is necessary to investigate whether 
percent-escaping is needed, and if so, explain how to do it.
> any uniformity of resolution services.

It was my assumption that the contents of the query component and 
guidelines on query usage will be included in the registry and to large 
extent supplied by the communities using persistent identifiers. As long 
as the technologies libraries, archives, museums, publishers etc. are 
using to manage digital resources are changing fast - and I expect 
technological change will continue for a long time - resolution services 
and information about them will be constantly changing.

For instance, a service like URI to URC (which provides metadata about 
the resource) requires a revision whenever
- a new metadata format is introduced, or
- an existing metadata format is revised, or
- a new search & retrieve protocol is introduced, or
- an existing search & retrieve protocol is updated.

IETF shall, I hope, provide a technical platform needed for maintaining 
query related documentation. But I am not sure if the actual maintenance 
work needs to / should be done in IETF. And if URNbis WG cannot agree on 
how to use URI fragment and query in the URN context, then it might 
happen that none of this work takes place under the IETF wing.

All persistent identifier communities are facing the challenge of how to 
make the resolvers smart, and how to share the information about the 
resolver capabilities in machine understandable form. To some extent, 
the standardization work needed has already been done by IETF or other 
standard bodies. For instance, SRU protocol has Explain operation via 
which it is possible to  retrieve a description of facilities available 
at an SRU server (see http://www.loc.gov/standards/sru/explain/). 
Explain may be used by URN resolvers to find out what SRU servers can do 
(in order to facilitate provision of URI to URC and other URN resolution 
services) but URN resolvers could also use SRU Explain to inform each 
other about the functionality they provide (such as URN namespaces and 
resolution services supported).

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: John C Klensin <[email-masked]>
Date: Tue, 24 Jun 2014 01:16:06 -0400

Juha and Dale,

A couple of observations which I hope don't get in our way in
the near term.

--On Monday, June 23, 2014 10:21 +0300 Juha Hakala
<[email-masked]> wrote:

>>> Fragments are ignored when URNs are resolved so they should
>>> cause no problems whatsoever.
>> Strictly speaking, current code to validate URIs could check
>> to see if the scheme is "urn", and if so, verify that no "#"
>> is present, as the current definition does not allow
>> fragments for URNs.  But in practice, I don't expect any code
>> to do this.
> 
> Clients such as web browsers should not even send URI
> fragments to servers such as URN resolvers. Since fragment has
> zero impact on how the URN is resolved, disallowing fragments
> from URNs on the client side would not make much sense.

We get all tangled up with the robustness principle here, but my
reading of the "reserved" language in 2141 is that any client or
system that uses a URN with a fragment is non-conformant to that
spec.  Speculating about what other systems should or should not
do with such things is far outside the specification and hence,
from a conformance standpoint, meaningless.
 
> We have discussed earlier on this list about the applicability
> of fragments in the URN context. If and only if a URN
> identifies a single digital manifestation of a resource (such
> as a PDF file) users can apply URI fragment any time after the
> resource has been identified and the identifier has been made
> actionable, provided that the MIME type of that file format
> supports the use of fragment. In such a case it is likely that
> the URN + fragment will be more persistent than URL + fragment.

That may be true, but it is also tied up with the reason I've
been skeptical about the association of "fragment" --even
approximately as defined for URLs and generic URIs-- to URNs at
all.  

With the understanding that I'm not going to try to suggest
anything resembling syntax or delimiters at this point (it seems
to me that agreement to the "URNs are not URI's" spec or
equivalent is prerequisite to such a proposal or  even having
such a discussion), it seems to me that a generic URN string
(not URI) is going to be, conceptually

    "URN" NID NSS [ServiceRequests...]

It will ultimately make a difference whether "a URN" is the
complete URN string as above or just urn:NID:NSS or, put
differently, whether the ServiceRequests are part of the NSS.
But it makes less difference in the near term than out trying to
make general URIs work for URNs would suggest.

In the above, a ServiceRequest is, again conceptually, a tuple
of 

   ServiceType ComparisonIndicator ServiceTarget
ReequestParameters...

ServiceType is nominally some sort of keyword.
ComparisonIndicator tells something trying to compare a pair of
URNs for identity whether that particular ServiceRequest counts
or should be ignored.  ServiceTarget identifies where the
ServiceRequest is to be sent and, depending on the ServiceType,
may be a keyword indicator or, at the risk of descending into
recursion hell, a URL or URN.  And RequestParameters are
anything the ServiceType definition says they are.

where any of those may be 

 - defined in the NID registration and omitted from
	(prohibited in) the URN string
 - allowed by the NID registration but explicitly
	included in the URN string
 - defined in the NID registration as a default but
	allowed in the URN string as an override.
 - prohibited entirely by the NID registration
	(effectively duplicating the "don't do that" rule of
	2141 on a per-NID basis)

Presumably the NID registration also gets to say whether
anything not required is prohibited, and the other variations on
that theme.

Requests/specificaions for location information, assorted
metadata, or model or actual objects themselves are then just
specialized ServiceRequests.  In particular, "Fragment"
disappears as a special type of syntax and reappears as a
Service Request that is applicable to some NIDs and not others
and whose meaning and action (and how it is "resolved") are
specified on an NID basis and as above.  "Query" disappears too,
not because it (or the syntax) are necessarily problematic but
because the term itself is misleading for many possible types of
ServiceRequests and therefore causes more confusion than it
clears up.

>>> the identifier itself (as in Handles, for instance) it is
>>> not possible to reserve some characters to this kind of
>>> special usage.
>> It's quite easy to reserve characters:  If the special
>> character "represents itself", that is, is in the underlying
>> Handle identifier, it must be represented in the URN as a
>> %-escape.  If the special character is used with the special
>> meaning, it must be written explicitly as "#" or "?".  This
>> is done in numerous places in URIs already.
> 
> OK. For the time being, bibliographic identifier standards do
> not have annexes explaining how to make them actionable in the
> Internet. If and when this is done, it is necessary to
> investigate whether percent-escaping is needed, and if so,
> explain how to do it.

I don't think Dale's comment and Juha's response have much to do
with each other.  More generally, as a long-term, and
much-wounded combatant in the i18n wars, I strongly recommend
that, if we separate URNs from the legacy problems of the
generic URI syntax, we take advantage of that to clean something
up, starting by separating "reserved character" from i18n issues
and creasing only one escape model that is prohibited except
where it is required and used as little as possible.
Specifically:

 - An NID registration specifies whether non-ASCII
	characters are allowed (the default, deriving from 2141,
	etc., is "no").
 - If they are not allowed, then they are not allowed,
	escaped or otherwise.
 - If they are allowed, the registration must specify
	what is allowed and how they are interpreted, preferably
	by normative reference to some other spec (e.g., IDNA
	U-labels, Unicode Identifiers, W3C CharMod-based
	specifications, PRECIS types) and, except in the most
	exceptional of per-NID circumstances, they appear as
	themselves, not escapes and certainly not as escaped
	UTF-8 octets.
 - If actual reserved characters are required to be used
	in their non-reserved sense, they are quoted, not
	reduced to error-prone numeric gibberish.

Just my opinion, of course, but I note that the above appears to
me to be completely consistent with the balance of Juha's note.

   best,
    john