Subject: Re: [urn] Thoughts on fragments, queries, and new URN namespaces

From: Juha Hakala <[email-masked]>
Date: Fri, 05 Jul 2013 15:53:04 +0300

Hello,

Several comments below.

On 16.6.2013 19:25, John C Klensin wrote:
> [snip] While I dislike several things about
> 3986, I don't see it as nearly as URN-hostile or, for that
> matter, different from its predecessors, as you obviously do.
Based on RFC 3986, it is possible to say things like this (quote from 
http://en.wikipedia.org/wiki/Uniform_resource_name):

> Since RFC 
> 3986^<http://en.wikipedia.org/wiki/Uniform_resource_name#cite_note-FOOTNOTERFC_39862005-2> 
> in 2005, the use of the term [URN] has been deprecated in favor of the 
> less-restrictive "URI", a view proposed by a joint working group 
> between the W3C and IETF. 
> ^<http://en.wikipedia.org/wiki/Uniform_resource_name#cite_note-FOOTNOTEW3C.2FIETF2001-3> 
> Both URNs (names) and 
> URLs<http://en.wikipedia.org/wiki/Uniform_resource_locator> (locators) 
> are URIs, and a particular URI may be a name and a locator at the same 
> time.

Confusing URNs (identifiers) and URLs (locations) like this and 
introducing URIs has not been helpful.  There are people whose 
requirements for persistence can be fulfilled by URLs, but organizations 
such as national archives, national libraries etc. which must preserve 
digital contents for centuries cannot trust on anything that is as 
technology dependent as URLs. For us, there is a fundamental difference 
between locators and persistent identifiers.
> Nonetheless, I think that getting this right first and then
> seeing what, if necessary has to be done to align things with
> 3968 (or vice versa) is a reasonable strategy.
Agreed.
>
> That said, I think we need a 2174bis draft to use as the basis
> for discussion.  Both in the the absence of a posted alternative
> and because I belief that most of what is needed is there, I
> would prefer to treat draft-ietf-urnbis-rfc2141bis-urn as that
> draft.
Yes, but the latest draft written by Alfred Hoenes does say a lot about 
fragment and query which can / should be re-used in the next version of 
rfc2141bis.

It is important to find a compromise which is acceptable both for IETF 
(from RFC 3986 point of view) and for communities who are using 
bibliographic and other identifiers and wish to make them actionable in 
the Internet. If this WG does not find a solution, then groups using 
persistent identifiers (Handles, DOIs, URNs and ARKs) will develop their 
own solutions. This is already happening, and some of the solutions I've 
seen are completely incompatible with the URI syntax. And even if the 
requirements of RFC 3986 are followed, interoperability may be in danger.
>> ...
>> Yes, I have a similar interpretation, and agree that RESERVED
>> does not imply "prohibited for all time".   But of course the
>> reason they were RESERVED is that we didn't know at the time
>> how to make them work and retain the persistence properties of
>> URNs.   It's not yet clear to me that we know how to do that
>> now, but at least I think I personally understand the issues
>> better than I did then.
URNs have been in use for more than a decade, which will help us this 
time. And there is also an emerging technical infrastructure for 
administering and preserving digital content for long term. Persistent 
identifiers have to fit into this infrastructure, and so that it will be 
easy to accommodate new functionality when it appears. This means, for 
instance, that specifying new resolution services and service related 
parameters is a simple and fast process.
>> And yet, people are accustomed to being able to compose URIs
>> out of base URIs and fragment IDs without having to worry
>> about whether the result will be valid.   They don't know that
>> it's stupid to do that, and nothing that 2141bis says is
>> likely to affect the vast majority of users that are currently
>> accustomed to appending fragment IDs to URIs.
It is not stupid to add a fragment if one can safely assume that the 
identified resource will not change. With URLs there is absolutely no 
guarantee of that. Within the URN system, there are namespaces such as 
URN:ISBN where fragments will work as long as the user has a tool with 
which the resource can be used.
>
> So, ignoring 3986 and reprising somewhat, I am suggesting that
> we
>
> (1) Allow fragment identifiers for URNs with the "#" delimiter
> (because switching delimiters to clearly denote these as
> "something else from what one might infer from 3986" would cause
> far more problems and incompatibility.
OK. But for practical reasons we should make clear that fragment is not 
part of the NSS and therefore does not identify anything. The fragment 
indicates just a location within the identified resource and is used by 
viewing applications once the entire resource has been retrieved.
>
> (2) Without restricting syntax, make the presence or absence of
> fragment identifiers a namespace issue (not a parsing one).
Many namespaces would not be able to use the URI fragment as a part of 
the NSS, because the identifier system prevents such extensions. If 
fragment is something that is added to the NSS when needed, this problem 
disappears. Analyzing semantic equivalence of two URNs is also a lot 
easier if the fragment can be ignored.

Generally, URI fragment can be applied in those URN namespaces in which 
the resolution produces something that has fragments in the URI syntax 
sense of the word. Specifying in advance which namespaces can use it and 
which ones cannot may not easy. Manifestation driven namespaces such as 
ISBN an easy; if I have for instance

urn:isbn:<isbn-number>

for an XML version of the book, it should be possible to use

urn:isbn:<isbn-number>#chapter2

to indicate the beginning of Chapter 2.

There are many identifiers / namespaces which do not cover digital 
resources themselves. But it may still be possible to use fragments. For 
instance, ISTC (International Standard Text Code) identifies textual 
works but not their manifestations. Resolving

urn:istc:<istc-number>

will by default produce work level metadata. This URN:

  urn:istc:<istc-number>#author

would still identify the entire metadata record, but the user should 
first see the author element within the metadata record.  As an aside,  
urn:istc:<istc-number>#author is not the persistent identifier of the 
author; that would be urn:isni:<isni-number>.
> 2141-compliant UNR processors, and processors associated with
> older namespaces, will presumably get some flavor of "syntax
> error - reserved character" errors or some other failure
> condition.  I don't see that as a problem.
If fragments are not part of the NSS, resolvers should just ignore them. 
And if my memory serves me right, web browsers should not even pass them 
on along the rest of the URI.
>
> (3) _Require_ that processors for namespaces that do not allow
> fragment identifiers respond to their presence with an error
> condition, whether that is a slightly-bogus "syntax error" or
> "character/fragments not allowed" report (for backward
> compatibility) or some flavor of "not allowed" or "not found".
I used to think that there are namespaces in which URI fragment can 
never be used. But this may not be the case since the fragment 
applicability depends on resolution services available. We cannot say 
that using fragment is a priori impossible for e.g. work identifiers 
such as ISTC.  But there will be situations when it is impossible to add 
a fragment since the retrieved resource does not support fragment usage.
>
> (4) _Require_ that processors for namespaces that perform
> dereferencing that do allow fragment identifiers (note that, if
> 2141 were followed, all of these would be new or revised) reject
> the things if they don't match identified fragment elements in
> the relevant resource.  I expect this requirement will be
> ignored in namespaces that are already using fragments, but at
> least we will have a clear line about compliance.
OK.
>
> (5) As discussed earlier, warn about some types of fragment
> identifiers are inconsistent with persistence and prohibit them
> in URNs for that reason.  I expect this may be ignored as well,
> but it will give us a fairly clear line about compliance and at
> least won't make anything worse or make the IETF look stupid.
It will be difficult to enforce this if the users utilize fragments 
after the URNs have been assigned. We cannot assume that they are 
familiar with persistence limitations. If anything, they will feel more 
comfortable using fragments with URNs than with URLs.
>
> (6) Make sure that, from a syntax standpoint, fragment
> identifiers are clearly part of the URN and including in the
> matching rules.   None of
>
>      URN:feline:...lion
>      URN:feline:...lion#African
>      URN:feline:...lion#Asian
>
> Match any of the others.
This is not how libraries, archives and museums intend to use fragments. 
Our aim is to allow the users to do things like this

urn:isbn:<isbn-number> (assigned by the publisher or the ISBN center)
urn:isbn:<isbn-number>#chapter10 (assigned by a user A)
urn:isbn:<isbn-number>#chapter 27 (assigned by a user B)

and so on. All of these URNs identify the same book and they are 
semantically equivalent since fragment is not part of the NSS.

As regards the example above, Library of Congress subject headings has 
68 hits with "lions" (see 
http://id.loc.gov/search/?q=lions&q=cs%3Ahttp%3A%2F%2Fid.loc.gov%2Fauthorities%2Fsubjects) 
including e.g. Lion -- Behavior -- South Africa, but all these have 
their own identifiers. Fragments are not and will never be used to 
specify different kind of lions in LCSH.

> I am agnostic about whether different media types that are used within 
> (or dereferenced from) the same namespace should be able to impose 
> their own restrictions on fragments as long as they don't broaden the 
> rules above. Clearly exactly what is permitted to be useful in a 
> fragment (uing the book example again, consider "#Chapter3" versus 
> "Chapter-III") is resource-dependent, not media type dependent. I'd 
> prefer to avoid the complexity of an additional layer of rules so will 
> ask for use cases, but I ultimately don't care very much. 

Yes, the precise form of the fragment depends on the encoding of the 
identified resource.
>> ...
>> In my mind at least, a URN shouldn't be associated with a
>> document or resource, but rather with a resource definition
>> that explains exactly what is being named, and that resource
>> definition is part of what you should get back when you
>> resolve the URN... so that the client has a better idea of how
>> specific that particular URN is (e.g. is it a particular
>> document or a particular version of a document or a particular
>> rendering of a particular version of a document, or something
>> narrower or broader?)
It would be useful if IETF folks had a good understanding of how 
libraries etc. will deal with the challenge of long term preservation 
and what role persistent identifiers will have in that.

If identifier assignment is a managed process (as it should be), 
different identifiers (URN namespaces) will be used for different 
purposes. Assuming that the resource is Hamlet, ISTC will be assigned 
for the work. Resolving the urn:istc will provide metadata record, 
including URNs of related works (like Hamlet movies), the play's 
different expressions (translations, illustrated versions, 
cartoons,...), URNs & URLs of resources about Hamlet, and so on. After 
selecting e.g. a specific German translation, the user will see its many 
manifestations.  Eventually he may choose one of them, such as freely 
available PDF version which looks like a printed book, or EPUB 3 version 
which adapts itself to the tablet the reader is using.

So there will be URNs which are associated with the resource, but there 
will also be many other kinds of URNs, and linking all of them together 
should help us to provide all users what they want, now and in the 
(very) distant future.
>>
>> But in practice we tend to talk about URNs being persistent
>> across changes in the document when we actually mean something
>> more subtle than that, much as we talk about URNs being
>> persistent when we're really referring to a property of the
>> binding between the URN and the resource [definition].
Agreed. From library point of view, work identifiers are persistent 
since works themselves are immaterial and will never change (as a result 
of changes in e.g. the file format of the resource). Persistence across 
changes in the document (for instance, as a result of migrating the 
resource in a new file format) is achieved via mapping the two 
manifestations and their URNs to one another directly and via the work 
level record.

>
> In principle, any URN can refer to any kind of resource.  If
> there are particular namespaces that constrain themselves as
> to only assign URNs to specific kinds of resources that have
> specific persistence properties, that's their business, but we
> shouldn't define general URN behavior in the presence of
> fragment IDs and/or query strings in such a way that it only
> works for those corner cases.
Most well managed URN namespaces are constrained one way or another. I 
would not call them corner cases but use cases. For me, totally 
uncontrolled namespace like UUID is a corner case since most resource 
which have urn:uuid will not be preserved for future generations.

URN should take into account well established identifiers and user 
groups which have resources to preserve digital resources for long term. 
A national library using urn:isbn is not a corner case but a key user 
group with fairly well specified needs - although I may not be able to 
express them clearly enough.
>
> I do think we have fundamental problems with where we are and
> where we are headed.  One possible conclusion from both your
> remarks and concerns and mine is that trying to establish a
> single persistent identifier model for arbitrary resources may
> have exceeded the IETF's knowledge and competence if, indeed, it
> is possible.  If that is even partially true, then trying to
> define them as an element of a syntax-sharing "uniform resource
> identifier" concept was probably a worse idea whether those
> identifiers are the URIs described in 3986 and its predecessors
> or something else.
Yes; RFC 3986 underestimated the complexity of long term preservation 
and the requirements digital archiving sets for identifiers and 
resolution services. Everything has to be made as simple as possible but 
not simpler, said Einstein, and the attempt to replace URLs and URNs 
with URIs goes to the too simple category.

>   It would have therefore been much easier
> (and more plausible) to define our persistent resource
> references separately from persistent resource-class references
> and to do so in a way that would be less likely to lead the
> naive but well intentioned (much less those who don't think or
> don't care) into situations that invite abuse and undermining
> the concept.   But, even if that very pessimistic analysis of
> the problem is the right one, the question today remains how we
> move forward to salvage the best of a bad situation, accepting
> the actually practices in the field and the potential for
> competing standards (or at least IETF standards that are ignored
> in practice) as part of the reality we have to consider.
If IETF fails to specify how to use fragment and query with URNs, 
different user communities will invent and re-invent this thing by 
themselves. The result will be duplicate effort and diminished 
interoperability. Given that we need to live with persistent identifiers 
for a long time, I wish this group can agree on principles and produce 
something useful. If not, the National Library of Finland will develop 
national standards based on the work done earlier in URNbis.

> I've found this discussion very educational, thought-provoking, and 
> illuminating. It has certainly clarified my thinking. 

Working with the IETF experts has definitely been all of the above - and 
sometimes also a little bit frustrating ;-). I have changed my mind 
about many things during the process, but there is one thing that I must 
take into account: the current & future technical infrastructure within 
which libraries shall apply URNs and URN resolution services. This 
includes the existing identifier systems and their usage policies which 
cannot be radically adjusted because of URN usage.

> I suspect from their silence that most of the rest of the WG's 
> participants are less enthused or perhaps just waiting for your 
> promised specific proposal. I don't think that the two-way 
> conversation will help much more until others step in or your I-D is 
> posted. So I'm going to go back to lurking and hoping for the best 
> until one of those things happens.

I will comment Keith's proposal next week.

All the best,

Juha

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

-- 

  Juha Hakala
  Senior advisor

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 05 Jul 2013 22:05:47 -0400

Juha,

This analysis is very helpful, at least for me.  It feels like
we are on our way to a discussion, rather than the staking out
of positions that I think has sometimes characterized this WG.
Detailed comments that I hope will be a step in that discussion
inline below.

--On Friday, July 05, 2013 15:53 +0300 Juha Hakala
<[email-masked]> wrote:

>> 3986^<http://en.wikipedia.org/wiki/Uniform_resource_name#cite
>> _note-FOOTNOTERFC_39862005-2>  in 2005, the use of the term
>> [URN] has been deprecated in favor of the  less-restrictive
>> "URI", a view proposed by a joint working group  between the
>> W3C and IETF. 
>> ^<http://en.wikipedia.org/wiki/Uniform_resource_name#cite_not
>> e-FOOTNOTEW3C.2FIETF2001-3>  Both URNs (names) and 
>> URLs<http://en.wikipedia.org/wiki/Uniform_resource_locator>
>> (locators)  are URIs, and a particular URI may be a name and
>> a locator at the same  time.
> 
> Confusing URNs (identifiers) and URLs (locations) like this
> and introducing URIs has not been helpful.  There are people
> whose requirements for persistence can be fulfilled by URLs,
> but organizations such as national archives, national
> libraries etc. which must preserve digital contents for
> centuries cannot trust on anything that is as technology
> dependent as URLs. For us, there is a fundamental difference

I agree with that distinction.  I think it is very important and
that it should be obvious to anyone who has thought about the
information theory/ information science aspects of this, rather
than trying to create Grand Unified Theories.  As I have said
before, I personally would have preferred a URN syntax that was
unmistakably not a member of the URI family, but I lost that
argument and probably for good reasons.  And it was lost, and
the URI concept invented, in the 90s, not in 2005.

>> 3968 (or vice versa) is a reasonable strategy.

In particular, what is really important about 3986, at least
IMO, is the syntax and the rules that bear directly on it.  More
philosophical discussions about the relationships among
identifier types ought to be possible to clarify without doing
any significant harm.

>> for discussion.  Both in the the absence of a posted
>> alternative and because I belief that most of what is needed
>> is there, I would prefer to treat
>> draft-ietf-urnbis-rfc2141bis-urn as that draft.

> Yes, but the latest draft written by Alfred Hoenes does say a
> lot about fragment and query which can / should be re-used in
> the next version of rfc2141bis.
 
> It is important to find a compromise which is acceptable both
> for IETF (from RFC 3986 point of view) and for communities who
> are using bibliographic and other identifiers and wish to make
> them actionable in the Internet. If this WG does not find a
> solution, then groups using persistent identifiers (Handles,
> DOIs, URNs and ARKs) will develop their own solutions. This is
> already happening, and some of the solutions I've seen are
> completely incompatible with the URI syntax. And even if the

I would prefer to avoid the concept of "compromise".  I think
there is a reasonable solution lurking out there and that your
note contributes to finding it.  If that is not the case, we
have gotten URNs seriously wrong, wrong enough that we need to
do some rather fundemantAal rethinking that might even lead to
deprecating them in favor of a different model.  I don't believe
that is likely to be necessary, but we shouldn't dismiss it out
of hand. 

Otherwise agreed.  And that is exactly what has brought me
reluctantly back into the discussion.

>>> how to make them work and retain the persistence properties
>>> of URNs.   It's not yet clear to me that we know how to do
>>> that now, but at least I think I personally understand the
>>> issues better than I did then.

> URNs have been in use for more than a decade, which will help
> us this time. And there is also an emerging technical
> infrastructure for administering and preserving digital
> content for long term. Persistent identifiers have to fit into
> this infrastructure, and so that it will be easy to
> accommodate new functionality when it appears. This means, for
> instance, that specifying new resolution services and service
> related parameters is a simple and fast process.

>>> about whether the result will be valid.   They don't know
>>> that it's stupid to do that, and nothing that 2141bis says is
>>> likely to affect the vast majority of users that are
>>> currently accustomed to appending fragment IDs to URIs.

> It is not stupid to add a fragment if one can safely assume
> that the identified resource will not change. With URLs there
> is absolutely no guarantee of that. Within the URN system,
> there are namespaces such as URN:ISBN where fragments will
> work as long as the user has a tool with which the resource
> can be used.

I think we need to accept two things, both of which should be
obvious.  (1) URNs and URLs have different semantics (not just
permanence properties.  As a result, the semantics of,
restriction on, and expectations of, fragment identifiers are
going to be different, even if the basic syntax framework is the
same.  (2)

>> "something else from what one might infer from 3986" would
>> cause far more problems and incompatibility.

> OK. But for practical reasons we should make clear that
> fragment is not part of the NSS and therefore does not
> identify anything. The fragment indicates just a location
> within the identified resource and is used by viewing
> applications once the entire resource has been retrieved.

Works for me.  Perhaps the "once...has been retrieved"
requirement is part of the rational boundary between (using a
book as an example) "URNs points to book, fragment marks chapter
beginning" and "URNs point to chapters with multiple URNs per
book and the book considered as a collection of chapters rather
than an object".

>> (2) Without restricting syntax, make the presence or absence
>> of fragment identifiers a namespace issue (not a parsing one).

> Many namespaces would not be able to use the URI fragment as a
> part of the NSS, because the identifier system prevents such
> extensions. If fragment is something that is added to the NSS
> when needed, this problem disappears. Analyzing semantic
> equivalence of two URNs is also a lot easier if the fragment
> can be ignored.

Again, works for me if we can get agreement on it.

> Generally, URI fragment can be applied in those URN namespaces
> in which the resolution produces something that has fragments
> in the URI syntax sense of the word. Specifying in advance
> which namespaces can use it and which ones cannot may not
> easy. Manifestation driven namespaces such as ISBN an easy; if
> I have for instance
> 
> urn:isbn:<isbn-number>
> 
> There are many identifiers / namespaces which do not cover
> digital resources themselves. But it may still be possible to
> use fragments. For instance, ISTC (International Standard Text
> Code) identifies textual works but not their manifestations.
> Resolving
> 
> urn:istc:<istc-number>
> 
> would still identify the entire metadata record, but the user
> should first see the author element within the metadata
> record.  As an aside,  urn:istc:<istc-number>#author is not
> the persistent identifier of the author; that would be
> urn:isni:<isni-number>.

I think I understand that.  If I do, I think it interacts with
the old problem (and one to which Keith's notes refer) of
distinguishing between "URN as name for object/resource" and
"URN as name for a pointer to something that leads to a
resource".  It might have been better had we separately those in
syntax or URI type identifiers, but too late for that.    I'd
also encourage folks to have a look at
https://datatracker.ietf.org/doc/draft-faltstrom-uri.  In one
sense, this is just NAPTR revisited, but, to the extent to which
a URI can reference a DNS name that could reference a URN that,
in turn, could involve or reference a mechanism for getting to
an object, we could find ourselves quite deep in levels of
abstraction and references.   While necessary sometimes, layered
references as probably the enemy of persistence and stability
assertions in many cases.

> If fragments are not part of the NSS, resolvers should just
> ignore them. And if my memory serves me right, web browsers
> should not even pass them on along the rest of the URI.
> 

> I used to think that there are namespaces in which URI
> fragment can never be used. But this may not be the case since
> the fragment applicability depends on resolution services
> available. We cannot say that using fragment is a priori
> impossible for e.g. work identifiers such as ISTC.  But there
> will be situations when it is impossible to add a fragment
> since the retrieved resource does not support fragment usage.

ok
 
>> dereferencing that do allow fragment identifiers (note that,
>> if 2141 were followed, all of these would be new or revised)
>> reject the things if they don't match identified fragment
>> elements in the relevant resource.  I expect this requirement
>> will be ignored in namespaces that are already using
>> fragments, but at least we will have a clear line about
>> compliance.
> OK.
>> 
>> identifiers are inconsistent with persistence and prohibit
>> them in URNs for that reason.  I expect this may be ignored
>> as well, but it will give us a fairly clear line about
>> compliance and at least won't make anything worse or make the
>> IETF look stupid.
> It will be difficult to enforce this if the users utilize
> fragments after the URNs have been assigned. We cannot assume
> that they are familiar with persistence limitations. If
> anything, they will feel more comfortable using fragments with
> URNs than with URLs.
>> 

> This is not how libraries, archives and museums intend to use
> fragments. Our aim is to allow the users to do things like this
> 
> and so on. All of these URNs identify the same book and they
> are semantically equivalent since fragment is not part of the
> NSS.
> 
> As regards the example above, Library of Congress subject
> headings has 68 hits with "lions" (see
> http://id.loc.gov/search/?q=lions&q=cs%3Ahttp%3A%2F%2Fid.loc.g
> ov%2Fauthorities%2Fsubjects) including e.g. Lion -- Behavior
> -- South Africa, but all these have their own identifiers.
> Fragments are not and will never be used to specify different
> kind of lions in LCSH.

I'm persuaded, or at least nearly so.  I think what is most
important is that either fragments are unambiguously part of the
URN (for matching and retrieval purposes) or they are not.

>>> resolve the URN... so that the client has a better idea of
>>> how specific that particular URN is (e.g. is it a particular
>>> document or a particular version of a document or a
>>> particular rendering of a particular version of a document,
>>> or something narrower or broader?)

> It would be useful if IETF folks had a good understanding of
> how libraries etc. will deal with the challenge of long term
> preservation and what role persistent identifiers will have in
> that.
> 
> If identifier assignment is a managed process (as it should
> be), different identifiers (URN namespaces) will be used for
> different purposes. Assuming that the resource is Hamlet, ISTC
> will be assigned for the work. Resolving the urn:istc will
> provide metadata record, including URNs of related works (like
> Hamlet movies), the play's different expressions
> (translations, illustrated versions, cartoons,...), URNs &
> URLs of resources about Hamlet, and so on. After selecting
> e.g. a specific German translation, the user will see its many
> manifestations.  Eventually he may choose one of them, such as
> freely available PDF version which looks like a printed book,
> or EPUB 3 version which adapts itself to the tablet the reader
> is using.
> 
> So there will be URNs which are associated with the resource,
> but there will also be many other kinds of URNs, and linking
> all of them together should help us to provide all users what
> they want, now and in the (very) distant future.

That is all completely reasonable and understandable, modulo the
concerns about undifferentiated layers of references above.
Perhaps that is not a problem, but it seems to me to have the
potential for a lot of complexity, referencing loops, etc.

I also wonder a bit about your "managed" assertion.  I think it
is safe to assume that some namespaces will be a lot more
managed than others and that many of them will face the
perennial problem with groups of Internet identifiers: the
inability to compel use of the management or registration
process if someone wants to go their own way.

>>> across changes in the document when we actually mean
>>> something more subtle than that, much as we talk about URNs
>>> being persistent when we're really referring to a property
>>> of the binding between the URN and the resource [definition].

> Agreed. From library point of view, work identifiers are
> persistent since works themselves are immaterial and will
> never change (as a result of changes in e.g. the file format
> of the resource). Persistence across changes in the document
> (for instance, as a result of migrating the resource in a new
> file format) is achieved via mapping the two manifestations
> and their URNs to one another directly and via the work level
> record.

> Most well managed URN namespaces are constrained one way or
> another. I would not call them corner cases but use cases. For
> me, totally uncontrolled namespace like UUID is a corner case
> since most resource which have urn:uuid will not be preserved
> for future generations.
> 
> URN should take into account well established identifiers and
> user groups which have resources to preserve digital resources
> for long term. A national library using urn:isbn is not a
> corner case but a key user group with fairly well specified
> needs - although I may not be able to express them clearly
> enough.

yes, but I think you and others are going to have to continue to
educate the rest of us if URNs are going to succeed.  I
appreciate your patience and willingness to do so.

>> have exceeded the IETF's knowledge and competence if, indeed,
>> it is possible.  If that is even partially true, then trying
>> to define them as an element of a syntax-sharing "uniform
>> resource identifier" concept was probably a worse idea
>> whether those identifiers are the URIs described in 3986 and
>> its predecessors or something else.

> Yes; RFC 3986 underestimated the complexity of long term
> preservation and the requirements digital archiving sets for
> identifiers and resolution services. Everything has to be made
> as simple as possible but not simpler, said Einstein, and the
> attempt to replace URLs and URNs with URIs goes to the too
> simple category.

See above about fixing statements of philosophy.

>...
>> I've found this discussion very educational,
>> thought-provoking, and  illuminating. It has certainly
>> clarified my thinking. 
 
> Working with the IETF experts has definitely been all of the
> above - and sometimes also a little bit frustrating ;-). I
> have changed my mind about many things during the process, but
> there is one thing that I must take into account: the current
> & future technical infrastructure within which libraries shall
> apply URNs and URN resolution services. This includes the
> existing identifier systems and their usage policies which

At the same time, I think all of us need to understand that not
all URNs (and namespaces) are the same and need to be treated
the same way.  For some, the experience and constraints of
libraries, archives, and similar systems are critical and should
at least set boundary conditions on the discussion and options.
For others, different considerations may apply.  Unless I'm
missing something. one thing that is going to turn out to be
important will be identifying the differences and which
namespaces fall into which categories and being clear about that.

>> I suspect from their silence that most of the rest of the
>> WG's  participants are less enthused or perhaps just waiting
>> for your  promised specific proposal. I don't think that the
>> two-way  conversation will help much more until others step
>> in or your I-D is  posted. So I'm going to go back to lurking
>> and hoping for the best until one of those things happens.
> 

Thanks.
    john

---

From: Juha Hakala <[email-masked]>
Date: Mon, 08 Jul 2013 13:33:17 +0300

Hello,

> of positions that I think has sometimes characterized this WG.
When the URN system were developed there were fewer issues between IETF 
and the communities using identifiers such as libraries. It looks like 
after a decade of using URNs the gap between theory and practice seems 
to have become wider. It is possible that this time the user communities 
have specific requirements, and finding an acceptable way of 
implementing them has been hard. Some of the issues we have faced have 
been fully justified, but sometimes theoretical discussions about the 
principles of identification on this list have established problems that 
are not really there.

There are quite a few persistent identifiers (PIDs) in use. Among the 
three most popular ones - Handle, DOI and URN - only URN is under IETF's 
wing. All of these identifiers are older than RFC 3986 and do not 
support either query  or fragment. If URNbis succeeds in adding them to 
URN syntax, Handle and DOI may follow - which would not be a bad thing.
> <snip> I personally would have preferred a URN syntax that was
I would like to see the arguments in favour of one URI to rule them all.
> identifier types ought to be possible to clarify without doing
I have assumed for quite a while now that we cannot divert from URI 
generic syntax. Such diversions are possible when using PIDs; there is a 
project using Handles which chose to use "@" as the fragment separator. 
But resolving such URIs correctly requires special software (in the case 
above, a tuned Handle resolver) and in the long term breaking URI syntax 
(or making private extensions to Handle syntax) is likely to be risky. 
Unfortunately persistent identifiers are for long term...
> that is likely to be necessary, but we shouldn't dismiss it out
Please keep in mind that tens of millions of URNs have been assigned 
already. They cannot be deprecated, and we cannot make any fundamental 
changes which would render old and new URNs non-interoperable. What we 
can do is to add new functionality, such as fragments and queries, and 
make it easier for people to use URNs by for instance changing the way 
in which services are registered.
> going to be different, even if the basic syntax framework is the
IMO, fragment is just a fragment, no matter whether it is attached to 
URL or to URN. Even when added to a URN it does not identify anything. 
Same functionality is expected; the viewing application should take the 
user to the indicated location within the resource. From functional 
point of view the main difference is that URL + fragment combination is 
much more fragile than URN + fragment. Document available in address X 
may change any time, but document with URN should not change, although 
it may be moved to a different location.

If and when we decide to use query, then URN will have a set of services 
and service parameters that have been specified as queries. For URLs 
nothing will be carved in stone like this.
OK.
> <snip>  I think what is most
Yes, we cannot allow both options. In practice, the only feasible option 
is that URI fragments are not part of the NSS, which means that they may 
be added to the URN, but from the point of resolution and semantic 
equivalence the URN is still the same.

For those who need to identify component parts ("fragments") of 
resources, the URN syntax should provide a means of doing that in a 
namespace specific manner.

> So there will be URNs which are associated with the resource, but 
> there will also be many other kinds of URNs, and linking all of them 
> together should help us to provide all users what they want, now and 
> in the (very) distant future.
Long term preservation based on migration will involve a lot of 
complexity. Over time there will be multiple versions of every resource 
that can be migrated, and a lot of supporting administrative metadata 
which describes the differences between successive versions of the 
document.

In order to make sense of all this, librarians have developed models 
such as FRBR (Functional Requirements for Bibliographic Records)

http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records

which describe how the different components of the system relate to one 
another. FRBR does not prevent the possibility of referencing loop, but 
a proper implementation of the model should not lead the users astray. 
On the other hand, making a complex model like FRBR work, we need 
persistent links between e.g. work and manifestation records. 
Experiments which have used database internal URLs have proven that.
> process if someone wants to go their own way.
Probably the main difference between Handle and DOI is that DOIs are 
better managed. There has been problems with DOI (a publisher purchasing 
a journal, and then changing the DOIs of all the articles) but they are 
less common than with Handles.

With URN there will be a lot of differences between namespaces. There is 
no management at all with UUID, and there may be namespaces where no 
resolution is provided, in which case any centralised management is a 
priori not necessary.

Poor service level (which will look like low reliability to the users) 
in some URN namespaces may undermine the value of the entire URN system. 
Therefore I regret the fact that it has been so easy to register URN 
namespaces. At least there should be an organization responsible of the 
namespace, in case there are questions about it.
> appreciate your patience and willingness to do so.
A particular strength of the URN system compared with other persistent 
identifiers is that it is fully compliant with existing bibliographic 
and other identifier systems. URN does not rival the old identifiers by 
specifying a new identifier system (unlike DOI, Handle and ARK); 
instead, with URN namespaces all the rules can be aligned according to 
the specific needs of the identifier community in question. ISBN 
embedded into URN can be extracted and parsed easily; ISBN embedded into 
DOI needs a lot more work (since part of ISBN goes into DOI prefix, and 
other part into DOI suffix, and it is not obvious that the DOI string is 
an ISBN).
> namespaces fall into which categories and being clear about that.
The only fundamental issue for me was the need of the URNs to be 
actionable. IMO non-functional URN (or a URN given to a resource which 
is not persistent) is counterproductive and should never be assigned. 
But we have decided that there can be URNs that will not provide any 
services, and that's it.

In the other end of the scale, we may have namespaces with plenty of 
services, with frequent changes both to the existing services 
(additional and deprecated features) and to the list of services (new 
services added, old ones removed).  We should design flexible means for 
specifying the services & service parameters available within a 
namespace in general, and provided by a resolver which supports the 
namespace in particular.

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Jul 2013 21:29:26 -0600

Hi Juha,

> principles of identification on this list have established problems that

So it seems. But in theory the IETF believes in running code, so the use
of URNs over the last 10+ years ought to count for something. :-)

> in which services are registered.

Might I ask you to explain what you mean by the registration of services
here? Are you referring to registration of namespace identifiers as in
RFC 3406, or something else?

>> going to be different, even if the basic syntax framework is the

Hi John, what was #2? ;-)

> URL or to URN. Even when added to a URN it does not identify anything.

Pendantic point: if that is true, then why do we call it a fragment
identifier component? Sure it must identify the "indicated location
within the resource", as you say...

Agreed.

> nothing will be carved in stone like this.

Juha, do you mean that we would define stable queries that apply to all
URNs (or all URNs within a namespace) and that service providers would
not be encouraged or allowed to define their own non-standard queries?

>> book and the book considered as a collection of chapters rather

Seems sensible.

Agreed.

> namespace specific manner.

Here again I need to ask something I queried about in another message:
do you mean that we would *not* allow fragments using URI '#' syntax but
instead would leave the syntax up to the namespace (e.g., one could use
'.' or some other character as the delimiter for fragments within a
given namespace)?

> in some URN namespaces may undermine the value of the entire URN system.

I'm not so sure about that, because I don't think that anyone really
considers or uses the URN system as a whole. People in publishing use
ISBN and ISSN and so on. Libraries use those and NBN. Folks in academia
might use SCHAC (RFC 6338). Developers and operators in the mobile
telephony space might use OMA and 3GPP (RFCs 4358 and 5279). Financial
applications might use SWIFT (RFC 3615). And so on.

> namespace, in case there are questions about it.

As far as I can see that's true of almost all formal namespaces (the
main exception I see is UUID).

> But we have decided that there can be URNs that will not provide any

Actually there are lots of "non-functional", "non-dereferencable"
namespaces. Maybe the organizations managing those mint far fewer URNs,
but I don't think it's productive to say that URNs that don't provide
services (e.g., you can't dereference them to retrieve metadata) are
counterproductive. As John says, they simply fall into a different
category. We could have a discussion about whether it might have made
sense to to define something other than URNs for those identifiers, but
that's water under the bridge now and IMHO it's best to try to
accomodate all the existing uses as best we can.

> namespace in general, and provided by a resolver which supports the

Mostly I see these services as a matter for specifications other than
2141bis. However, I now agree that we need to at least allow queries and
fragments in the syntax (but not within the NSS), and that's all I care
about for 2141bis. I'll leave documentation of services and URN
resolution to someone braver than I. :-)

Peter

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

---

From: Juha Hakala <[email-masked]>
Date: Tue, 09 Jul 2013 08:52:10 +0300

Hello Peter,

> RFC 3406, or something else?
I mean the registration of new / altered resolution services. At the 
moment we have (experimental) RFC 2483 which describes a fixed set of 
resolution services necessary for URN resolution. These services are 
based on the technical infrastructure of late 90's.

Based on the experiences the National Library of Finland has got from 
maintaining both a national URN resolution service and a number of 
digital library applications, there are a few improvements needed:

1. RFC 2483 assumes that the resolution services do not need parameters. 
For instance, if a user requests metadata about the resource, one size 
fits all - the (non-existent) URC will do. If only it were that simple: 
in practice, a user may need descriptive metadata which can be available 
in many formats (MARC 21, Dublin Core, EAD, LIDO and so on) or 
administrative metadata which has its own formats. So instead of having 
just two services (I2C, or URI to URC, and I2Cs) we shall need either 
one service for each metadata format which would be cumbersome, or 
enriched I2C service which allows the user to specify either the format 
or the metadata type (descriptive or administrative; the latter consists 
of technical, preservation and rights metadata) wanted.

2. Specifying the services in an RFC is based on the assumption that the 
set of URI resolution services is relatively stable and does not require 
frequent updates. It is not likely that is the case, since resolution 
services depend on a technical infrastructure which has been changing 
fast. Emerging services, such as digital archives, will enable us to 
provide new kinds of services, which from URI resolution point of view 
may be either entirely new services or additional parameters to existing 
ones.

Some examples of services that have emerged since RFC 2483 was written 
(assuming, among other things, that there is a fully functional digital 
archive application which interacts with the URN resolver):

A. On the basis of the URN of work X, show me all its manifestations 
(PDF, OOXML, EPUB 3 etc.)
B. On the basis of the URN of work X, show me all the other works 
related to it
C. Based on the URN of manifestation X, show me all the other 
manifestations of the same work
D. On the basis of preservation metadata, show me the differences 
(resulting from successive migrations) between the manifestations of work X
E.  On the basis of technical metadata, show me the software and 
hardware requirements of using manifestation X
F. On the basis of rights metadata, show me if I can access copy Y of 
manifestation X

3. RFC 2483 does not enable specification of formal, informal and 
experimental resolution services. Such division might be useful (see 
below).

  Alfred Hoenes and myself concluded that what we need is an IANA URN 
resolution service registry (similar to the URN namespace registry), and 
an RFC which specifies how such a registry is to be maintained.

I believe that the maintenance of the service registry is less 
challenging than maintenance of the namespace registry. For each new URN 
namespace, IANA / IETF should estimate if the namespace is managed well 
enough and whether the identifier system meets the requirements. For 
resolution service / service parameter no such scrutiny is needed. But 
it is important to maintain a central registry if them, so as to 
guarantee that the users of the URNs do not re-invent the wheel.

IANA may decide that maintaining this registry is not within its scope. 
In that case URNbis should find another volunteer. IMO it is not 
possible to write and RFC which specifies URN resolution service 
registry and its maintenance procedure without telling who runs the show.

> within the resource", as you say...
I do not call it fragment identifier; you do.

Let's use an analogy. Every house in Finland has an address. But Finnish 
Ordnance Survey does not use the address as an identifier for the house; 
they have an entirely different system for that. The names of cities and 
streets can change, so address is not persistent enough to serve as an 
identifier.

If I want to identify an article within a journal issue, I'd never use 
the identifier of the issue and a fragment which shows where the article 
begins within the issue. The same article may be / will be published in 
many other places, independently of the original context (the journal 
issue). Any identifier which assumes that the issue is there might soon 
become a real pain in the neck. It is much better idea to have separate 
identifier for the article, although in order to access it one may use 
also the URN of the issue plus fragment.

When the journal and the issue are migrated into new file format, new 
identifiers will of course be assigned. A link between the old and new 
manifestation is established in metadata, with the description of the 
differences between the two manifestations in preservation metadata.
> not be encouraged or allowed to define their own non-standard queries?
I would definitely not encourage the service providers to define 
non-standard queries, since that would reduce interoperability between 
URN resolvers. If I need to get e.g. technical metadata for a document 
held in the digital archive of the National Library of Norway, it would 
be really annoying if my client app should use different service + 
service parameter combination than our resolver in Finland uses.

But it should be OK to allow service providers to specify experimental 
queries and query parameters for internal usage, with an assumption that 
such things may become formal services / service parameters in the future.
> '.' or some other character as the delimiter for fragments within a
Yes. In URNs, fragment using the URI "#" syntax should not have any 
meaning beyond what RFC 3986 assigns for it. Any diversion might cause 
us problems now or in the (more or less distant) future.

Namespace specific solutions for identifying fragments (or component 
parts of documents or whatever the fragment is called) may use basically 
any means for fragment identification, except the URI generic syntax. 
Resolvers which cope with the identifiers within that namespace must 
know how treat these URNs. Most often the process will be 
straightforward since identifiers for component parts are the same as 
the identifiers for host documents.
OK.
> resolution to someone braver than I. :-)
Great; allowing both fragment and query and thus aligning URNs with the 
URI syntax as specified in RFC 3986 is at least a very good start :-). 
And Alfred Hoenes has already written an I-D which outlines the IANA 
registry for URN resolution services, so there is no need to start from 
scratch.

  Juha

-- 

  Juha Hakala
  Senior advisor

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Jul 2013 09:58:36 -0600

> of technical, preservation and rights metadata) wanted.

Thanks, that is helpful.

At this time, my main interest is in finding text for 2141bis and
3406bis that we can agree on so that the base specs can be advanced.
Once that is done, I will leave work on 2483bis to people (like you) who
know more about resolution services.

> an RFC which specifies how such a registry is to be maintained.

Juha, do you think this is something that needs to be specified in
3406bis? My feeling is that the IANA URN Resolution Services Registry
would be defined by 2483bis.

> namespace, 

Well, for each new URN namespace for which resolution services are
expected / defined. :-)

> IANA / IETF should estimate if the namespace is managed well
> enough and whether the identifier system meets the requirements. 

Meets the requirements of 3406bis or 2483bis?

IMHO it is not IANA's job to perform this estimation, it is the job of
the URN-NID expert reviewers or, perhaps even better, a task that the
broader URN community needs to take seriously. If another SDO write an
I-D and requests a NID, then we might treat that as we do for things
like media types now.

> For

Agreed.

> registry and its maintenance procedure without telling who runs the show.

I see IANA as a mere registrar here, not as a gatekeeper.

> I do not call it fragment identifier; you do.

I do not call it fragment identifier; RFC 3986 does. :-)

I am trying to understand what you mean by fragment here. I think it is
not the same as what RFC 3986 means, so we might want to use a different
term for "sub-parts of a thing identified by a URN that are not flagged
by the presence of an RFC 3986 fragment identifier". Shall we call it a
"segment" to prevent confusion?

> also the URN of the issue plus fragment.

URN plus RFC 3986 fragment identifier or URN plus namespace-specific
"segment distinguisher"?

> differences between the two manifestations in preservation metadata.

That all makes sense. Thanks for the explanation.

Agreed.

> the identifiers for host documents.

That seems sensible.

> registry for URN resolution services, so there is no need to start from

Excellent.

I am out of time for the moment, but tonight I will try to work on
proposed text for 2141bis so that we can move forward. (I would very
much like to submit a revised I-D before the submission deadline next
Monday.)

Peter

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

---

From: Juha Hakala <[email-masked]>
Date: Wed, 10 Jul 2013 11:08:09 +0300

Hi,

On 9.7.2013 18:58, Peter Saint-Andre wrote:
> Thanks, that is helpful. At this time, my main interest is in finding 
> text for 2141bis and 3406bis that we can agree on so that the base 
> specs can be advanced. Once that is done, I will leave work on 2483bis 
> to people (like you) who know more about resolution services. 

OK.
> would be defined by 2483bis.
I share your view that 2483bis is a better place to the registry 
specification than 3406bis. But 3406bis must refer to the registry 
specification, so that people know how to proceed when their namespace 
registrations include new services / service parameters. 3406bis might 
also be a place where to explain the problems which may be caused by 
using private services / service parameters.

An additional benefit from using rfc2483bis is that we can open the 
registry to other PID systems, in case they want to formally register 
the services they provide. For instance the ARK system 
(http://datatracker.ietf.org/doc/draft-kunze-ark/) specifies three 
services, one of which is not covered in RFC 2483 (access to the 
statement which describes the host organisation's commitment to preserve 
the resource in long term). ARK has its own syntactic tools to request 
this service, but it might still be possible to specify it in the 
registry so as to improve interoperability between these two identifiers.
OK.
> Meets the requirements of 3406bis or 2483bis?
No, I mean the generic requirements for URNs (persistent, 
location-independent and preferably also unique) which are listed in RFC 
2141 and in many other RFCs. Namespace registration request should 
contain enough information to make sure that these requirements are met. 
The registration should also describe how the namespace is managed, but 
it will be harder to evaluate this information.
> I-D and requests a NID, then we might treat that as we do for things
OK. I thought that the URN-NID expert reviewers are using the IANA hat 
when they are performing the job.

I have no idea if any applications have ever been turned down, due to 
technical or other shortcomings.

As of this writing the URN community is not yet ready to take over the 
responsibility of reviewing namespace registration requests. But 
eventually it may be a good idea to delegate the task from IANA to the 
users of the URN system themselves.
> I see IANA as a mere registrar here, not as a gatekeeper.
OK. It seems to me that maintenance of the service registry is also 
something that is in the interests of the URN user community. 
Co-ordination would reduce the possibility of registering overlapping 
services and minimize the risk of simultaneous preparation of identical 
service registration requests.
> I do not call it fragment identifier; RFC 3986 does. :-)
Unfortunately...
> "segment" to prevent confusion?
When RFC 3986 fragment is added to the URN, even "fragment identifier" 
is confusing indeed since we do not want to give it any role in 
identification. It is very hard for me to see what the fragment would 
identify since fragment can in theory point to any location within the 
document. There does not need to be any subordinate resources (although 
there can be one).

Can we just say that URI fragment can be used to indicate a location 
within the identified resource, but that in the URN system it does not 
formally identify any component parts of the resource?

Then we can make a statement that there can be namespace specific 
practices for identification of component parts, such as "an article in 
a single issue of a periodical, a chapter in a book, a band on a 
phonodisc, and a map on a single sheet that contains several maps", and 
that these practices shall be specified in namespace registration requests.

>
>   It is much better idea to have separate
The two options above could be described as "adding RFC 3986 fragment to 
the URN of a resource (serial issue)", and "creating a URN for a 
component part of the resource (serial article)". The former approach 
allows the users to locate the article within the issue and is 
sufficient for e.g. providing a reference to the article.
> much like to submit a revised I-D before the submission deadline next 

OK. I hope you'll be able to finish the work on time.

The task may be a bit easier if you cut and paste relevant sections from 
the last 2141bis I-D written by Alfred Hoenes back to your text. There 
is a lot of stuff Alfred wrote that does not require too much editing 
now that we agree (more or less) on e.g. how to use fragment and query. 
For instance the analysis of semantic equivalence of various URNs in 
Alfred's text was based on the idea that fragment and query are not part 
of the NSS.

Whether you use the old I-D or not, it would be nice if Alfred were 
mentioned as one of the authors since he had a major role in e.g. 
formulating the usage of fragment and query.

Once the new version of the 2141bis is complete, I'll check what needs 
to be done to the ISBN and NBN namespace registrations. Any work on 
2483bis has to wait for a while, not least because for now it is not 
even on the agenda of URNbis.

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Jul 2013 16:06:01 -0600

Proposed text at end.

> much like to submit a revised I-D before the submission deadline next

Here is some proposed text for 2141bis.

SECTION 5

OLD

      URN       = "urn" ":" NID ":" NSS
                ;
                ; the URI scheme ("urn") is case-insensitive
                ;
      NID       = (alphanum) 0*30(ldh) (alphanum)
                ;
                ; alphanum is defined in RFC 3986
                ;
      ldh       = alphanum / "-"
      NSS       = 1*(pchar)
                ;
                ; pchar is defined in RFC 3986
                ;

NEW

      namestring    = assigned-name [ "?" query ] [ "#" fragment ]
                    ;
                    ; query and fragment are defined in RFC 3986
                    ;
      assigned-name = "urn" ":" NID ":" NSS
                    ;
                    ; the URI scheme ("urn") is case-insensitive
                    ;
      NID           = (alphanum) 0*30(ldh) (alphanum)
                    ;
                    ; alphanum is defined in RFC 3986
                    ;
      ldh           = alphanum / "-"
      NSS           = 1*(pchar)
                    ;
                    ; pchar is defined in RFC 3986
                    ;

SECTION 5.3 (new section)

5.3.  Query Component and Fragment Identifier Component

   The URI specification [RFC3986] allows a query component, a fragment
   identifier component, or both after the path component of a URI,
   where the character '?' is used as a separator to denote the
   beginning of the query component and the character '#' is used as a
   separator to denote the beginning of the fragment identifier
   component.  The original URN syntax specification [RFC2141] reserved
   the '?' and '#' characters for future developments.  This
   specification aligns URN syntax with URI syntax by allowing the query
   component and fragment identifier component after (not within) the
   Namespace Specific String (NSS).  However, this specification does
   not define the applicability and semantics of the query component or
   the fragment identifier component in URNs.  Additional specifications
   might establish these matters for URN-related services (such as
   resolution) or for individual URN namespaces.  In particular, methods
   for distinguishing the component parts of resources named by URNs
   within individual namespaces are the responsibility of specifications
   for those namespaces (e.g., they might use URI fragment identifier
   component syntax or some namespace-specific syntax).

Feedback is welcome.

Peter

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

---

From: Juha Hakala <[email-masked]>
Date: Thu, 11 Jul 2013 10:14:36 +0300

Hello,

A few suggestions:

>                      ; pchar is defined in RFC 3986
Fine with me. Some (most?) query / fragment combinations would not make 
sense, but that doesn't need to be discussed here.
>     Namespace Specific String (NSS).
I do not know how obvious things should be made. But you could add here 
something like this:

In the URN context, query can be used for e.g. requesting a resolution 
service. Fragment can be used for distinguishing a particular location 
within or a segment of a resource identified by the NSS.
> However, this specification does
How about "responsibility of namespace registration requests and other 
specifications for those namespaces (e.g., they may use some 
namespace-specific syntax)."?

Giving URI fragment identifier a prominent role here might confuse 
people and make them believe that fragments do identify something after 
all.

Is it necessary to mention here or somewhere else in 2141bis that the 
identifier assignment can be a managed process (depending on the 
namespace), but anyone can add a query and / or fragment to basically 
any URN once the identifier has been assigned.

Juha

-- 

  Juha Hakala
  Senior advisor

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Jul 2013 17:51:17 -0600

> A few suggestions:

Thanks for the feedback. We're getting closer...

Agreed.

> people and make them believe that fragments do identify something after

Here is revised text:

###

   This specification does not define the applicability and semantics of
   the query component or the fragment identifier component in URNs.
   Additional specifications might establish these matters for URN-
   related services (such as resolution) or for individual URN
   namespaces.  For example, it is possible that the query component
   might be used in requests to URN resolution services, or that the URI
   fragment component might be used to distinguish the component parts
   of resources named by URNs.  However, defining such usage is left to
   specifications for URN resolution services, namespace registration
   requests and specifications for individual namespaces (which might
   use some namespace-specific syntax instead of the URI fragment
   component), and other appropriate documentation (such as policy
   documents governing the management of a given URN namespace).

###

> any URN once the identifier has been assigned.

Perhaps. I'll look at this further a bit later tonight and propose some
more text.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Jul 2013 22:08:23 -0600

> Perhaps. I'll look at this further a bit later tonight and propose some

Further tweaking. Thanks to Juha for the suggestions.

###

   This specification does not define the applicability and semantics of
   the query component or the fragment identifier component in URNs.
   Additional specifications might establish these matters for URN-
   related services (such as resolution) or for individual URN
   namespaces.  For example, it is possible that the query component
   might be used in requests to URN resolution services, or that the
   fragment identifier component might be used to distinguish the
   component parts of resources named by URNs.  However, defining such
   usage is left to specifications for URN resolution services,
   namespace registration requests and specifications for individual
   namespaces (which might use some namespace-specific syntax instead of
   the URI fragment identifier component), and other appropriate
   documentation (such as policy documents governing the management of a
   given URN namespace).

   Although URN assignment is often a managed process (see
   [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]), the query component or
   fragment identifier component can be appended after the NSS once a
   URN has been assigned in accordance with the rules for a given
   namespace.

###

Peter

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