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

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 25 Jun 2014 14:09:22 +0000

John,

[...]
> > 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.

Having looked at the Best Practices for Fragment Identifiers [1] (which I wasn't aware of) the task is really daunting. *If* we can talk about FIs in the context of URNs at all, it has to be as "semantic fragid structures".

> 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.
> 
[...]
> 
> 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.

Apart from the name "query", do you think this could be done using the URI query syntax?

[1] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids

Best,

Lars

---

From: Juha Hakala <[email-masked]>
Date: Thu, 26 Jun 2014 11:21:58 +0300

Hello,

> Having looked at the Best Practices for Fragment Identifiers [1] (which I wasn't aware of) the task is really daunting. *If* we can talk about FIs in the context of URNs at all, it has to be as "se…

Insisting that fragments identify something makes this best practices 
document more complicated than it needs to be. It would be easier to 
write a text with the title "Best practices for URI fragments and media 
type definitions".

Even in [1] the author occasionally avoids the term identification. For 
instance on chapter C.5 URI http://example.org/potter#hermione just 
"means" the person named Hermione Granger, but does not "identify" her.

When fragment was first introduced to the URI syntax it may have made 
sense to think of it as an identifier of something. But over the years 
novel usages have been invented, and the problems inherent in this 
approach have become more obvious. For instance, does

|http://example.com/document.txt#match=[rR][fF][cC]

identify words (every "RFC" and "rfc" within the document) or locations 
of these words within document.txt or something else? And if the base 
document changes so that there are no more matches, what does the 
fragment identify? Or, does

|||http://example.com/document.txt#match=[J][U][H][A][H][A][K][A][L][A]

identify me or just two words or something else? |

Fragments can also be used for searching, using syntax |||#!s!search 
terms. So the fragment this URI
||
|||http://example.com/index.html#!s3!RFC

would instruct the browser to search the third occurrence of the term 
RFC in the document. But does this fragment identify that particular 
word, or that location in the resource? ||Or, if the fragment is the MD5 
checksum of a document, which fragment of the document is identified?
|
Technical issues aside, the key problem here is that fragment assignment 
is completely un-managed process, even more so than naming of files and 
creation of URLs. Anyone who sees identifier assignment as something 
controlled should a priori have major issue with the idea of "fragment 
identifier".

There are a lot of reasons why fragments must not be part of the 
namespace specific strings. But I see no problem in allowing them in 
URNs, as long as we don't think of them as identifiers. I fully agree 
with [1] that "authors can use fragments within referenced URIs (that 
is, URLs and URNs) to address content on documents published by others" .

>> differently, whether the ServiceRequests are part of the NSS.

Like URI queries, ServiceRequests must not be part of the NSS. Assigning 
an identifier to a resource is (ideally) a managed process, and 
identifiers themselves must never change. ServiceRequests are dependent 
on technical infrastructure which supports URN resolution, and may or 
may not be present on URNs to be resolved.

>> ServiceType is nominally some sort of keyword.

OK. RFC 2483 defines a handful of these keywords and services, but not 
nearly enough.

>> or should be ignored.

I am not sure I understand the need for ComparisonIndicator.

>> ServiceTarget identifies where the
>> recursion hell, a URL or URN.

Including ServiceTarget into ServiceRequest may not be necessary. URN 
resolver appropriate for the namespace in question should know which 
server is able to cater for ServiceRequests of given type. For instance, 
if a user wants full metadata about an academid dissertation, the 
resolver "knows" that the national bibliography should be able to 
fulfill the request. But if the document itself is requested, open 
repository (using Fedora, DSpace or some other such application) is 
better choice.

>> And RequestParameters are

Yes, and the number of parameters required will vary a lot depending on 
the ServiceType.

>> ServiceRequests and therefore causes more confusion than it

I am not sure it is  necessary / productive to make fragments reappear 
as ServiceRequest. As I see it, Service Requests are something that URN 
resolvers must deal with, whereas fragments will be processed by clients 
such as web browsers, both for URLs and URNs. At least for now I cannot 
see a need for a fragment-like Service Request, or understand properly 
what these services would be like.

Using URI query for passing ServiceRequests looks like an attractive 
option with minimal technical overhead. Whether this kind of use of 
query would be confusing, and whether using some other mechanism would 
make things more clear I can't tell, before seeing more detailed 
proposal on how to proceed. Like Lars, I wonder if the intention is to 
drop just the word query, or the syntax as well.

Juha

-- 

  Juha Hakala
  Senior advisor

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 26 Jun 2014 08:13:59 -0400

Hi Juha and Lars,

Some comments below, mostly to clarify my earlier note to which
both of you partially responded.  First, and most important,
please understand that, while I have biases and opinions about
URNs and their proper definition and use, I'm trying to be
completely pragmatic about this.  That means I am putting three
strategic principles ahead of declarations about what is or is
not correct from some perspective.  Those pragmatic principles
are 

 -- try to accommodate all of those who think URNs are
	necessary, i.e., that they are distinct from URLs.
	
 -- try to avoid getting bogged down in declarative/
	definitional statements about what is and is not correct
	in the abstract.
	
 -- avoid a fork in the standard in which we have
	multiple, conflicting, definitions or criteria for URNs
	around.

I say "opinions and biases" because, while I have preferences
about what I believe to be correct, they are not nearly as
informed as yours nor nearly as focused on the needs of a small
cluster of applications as those of some others.  Instead, for
the purposes on these discussions generally and getting this
work to a successful conclusion in particular, I'm just trying
to listen to comments and generate a model that is general
enough to accommodate all of those that seem to be based in
clear needs and applications (specifically, I'm no longer
interested in the positions of those who believe that URNs, or
the distinctions that define the need for them, are fictional or
irrelevant).

This is a radical point of view.  I generally don't like radical
points of view but just don't see any other way out for us.  See
[3] for a further caveat about this note.

It is just a corollary to the above that I am trying to avoid
discussions about what is or is not "persistent" (or "persistent
enough") and what is or is not formally an "identifier".  I
think the much more pragmatic question of naming constructs that
are independent of resolution or accessing method(s) and which
have to be usable for periods of time that range from weeks or
months to many centuries, with those difference in time
expectations depending on the NID, not the fundamental nature of
URNs.

This is a difficult discussion and many of us (certainly
including myself) seem easily distracted into discussions that
don't move the URN effort forward.  They are very interesting
and philosophically important -- that is probably what makes
them such tempting distractions -- but getting diverted into
them is really not helpful.  I'm trying to be very resistant to
those discussions and hope that others will grow more resistant
to them too.

So, with that background...

--On Thursday, June 26, 2014 11:21 +0300 Juha Hakala
<[email-masked]> wrote:

>...
>>>> 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.

>>> approximately as defined for URLs and generic URIs-- to URNs
>>> at all.

>> Having looked at the Best Practices for Fragment Identifiers
>> [1] (which I wasn't aware of) the task is really daunting.
>> *If* we can talk about FIs in the context of URNs at all, it
>> has to be as "semantic fragid structures".
> 
> Insisting that fragments identify something makes this best
> practices document more complicated than it needs to be. It
> would be easier to write a text with the title "Best practices
> for URI fragments and media type definitions".
>...

Here, as elsewhere in this note, the principles above cause me
to take a position very different from where you (and Lars) are
going -- not contradictory, but orthogonal.  Because of those
principles and the question of the legitimacy of URNs as a
construction separate from URLs (or URLs generalized into URIs),
I believe the document cited [1] is simply irrelevant.   I
really want to see us discuss and evolve URNs in a way that
responds to needs --as concrete as possible-- identified by
legitimate communities, not whether the results (or thinking)
conform to some notions about generalized HTTP URLs.    As I
tried to say in my earlier note, I'd like to move away from the
terms "fragment" and "query" entirely, just because their
historical association with 3986 creates confusion and leads to
discussions that primarily apply to URLs (and maybe HTTP URLs in
particular) and whether those other specs require entire
conformance or support of particular capabilities in URNs.  

I note that this "best practices" document is still a Proposed
Recommendation and not authoritative, even within W3C, for even
HTTP URLs.  I don't believe that debating the particular
terminology the editor used is helpful to making progress on
URNs and, while we might try to use what we think we know now
about URNs to refine it, I think such an effort would impede
moving forward with a [non-forked] updated URN spec.   Put
differently, my proposed and pragmatic point of view (including
the separation of URNs from the generic URI spec) says that this
document is simply not relevant to URNs and that trying to make
it relevant (or assert its relevancy) just gets in our way.

>...
> would instruct the browser to search the third occurrence of
> the term RFC in the document. But does this fragment identify
> that particular word, or that location in the resource? ||Or,
> if the fragment is the MD5 checksum of a document, which
> fragment of the document is identified?

I want to stay with "irrelevant" and away from distractions, but
the above helps show why that position is important: if one
believes that URNs have to be stable independent of what happens
with method-dependent "identifiers" (or "locators", etc.), then
I think we have to simply avoid getting entangled by statements
about instructions to browsers because we cannot to know what a
"browser" is with sufficient clarity, abstraction, and
persistence/stability.

> Technical issues aside, the key problem here is that fragment
> assignment is completely un-managed process, even more so than
> naming of files and creation of URLs. Anyone who sees
> identifier assignment as something controlled should a priori
> have major issue with the idea of "fragment identifier".

Yes.  But, even while I agree with that distinction, I think it
leads us around in a circle and back to another distraction.  If
one steps back from the 3986 "generic" definition and thinks of
fragments were, IIR, they started, we end up with two types of
prototype fragments.  One involves a marked-up document (not
necessarily HTML but certainly thought of in that context) with
anchor labels (definitely "identifiers" in the context of that
document) and the other a counted object in a specific form of a
document.  In both cases the "fragment identifier" is just a
pointer that is as persistent as the object itself.  I note
that, in an alternate reality, that view generalizes.  For
example, ISBNs could have been defined to include numbered
chapters and chapter designations as an intrinsic property of
the work being identified/numbered.  That wasn't done for
_really_ good reasons, but, had it been done, 
    urn:isbn:...#Chapter3
would have been fully as meaningful as an HTTP URL that locates
an HTML object and that contains a fragment "identifier".

What is important about that hypothetical variant ISBN is that
the definition of "fragment" becomes completely dependent on the
properties of the NID definition, just as [1] is very dependent
on assumed properties of HTTP URLs that point to HTML objects.
The problem arises only when one tries to make generic
statements about URLs (or generic URIs) independent of what they
locate, identify, or with which they are otherwise associated.

> There are a lot of reasons why fragments must not be part of
> the namespace specific strings. But I see no problem in
> allowing them in URNs, as long as we don't think of them as
> identifiers. I fully agree with [1] that "authors can use
> fragments within referenced URIs (that is, URLs and URNs) to
> address content on documents published by others" .

And my problem is that, in a fully general sense (more general
than either HTTP-URLs references HTML-like objects or your
library/ museum/ etc., context) I'm not sure what many of the
words you mean above mean.  The words themselves are
context-dependent.  Using them as if they are broad generic
terms introduces confusion; trying to define them precisely
enough to cover all possible cases, including future ones, is,
in the "get to a non-forked URN" context, a distraction.

See below.

>...
> Like URI queries, ServiceRequests must not be part of the NSS.
> Assigning an identifier to a resource is (ideally) a managed
> process, and identifiers themselves must never change.
> ServiceRequests are dependent on technical infrastructure
> which supports URN resolution, and may or may not be present
> on URNs to be resolved.

If you equate "part of the NSS" with "differences in it at the
bit level cause two URNs to compare non-equal" then that is a
discussion I'm trying to avoid.  Again, I can completely agree
with you in your context; I'm just trying to avoid needing to
have the discussion, much less reach consensus about the
answers, in a much more general context.  And that leads
directly to "ComparisonIndicator", so see below.
 
>>> 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
>>> 
> OK. RFC 2483 defines a handful of these keywords and services,
> but not nearly enough.

Another example of what I'm trying to avoid.  I am certain your
statement above is true.  I am equally certain the trying to
define (or even adequately characterize) the others will bog us
down for a very long time and lead us to Plan C or D [2].  So
I'm trying to push that problem away by making those services
and keywords a per-NID matter.  If it turns out that we can
later make groups of NIDs into categories that share some set of
services and keywords, that would be great.  But, if we make
doing so, or even proving that we can do so, a condition for
URNs, then we will be back to where we were when I first killed
the URI WG.

>>> ComparisonIndicator tells something trying to compare a pair
>>> of URNs for identity whether that particular ServiceRequest
>>> counts or should be ignored.
> 

It is a trick to avoid having to resolve the question of whether
a particular Service Request --or Service Requests in general--
are "part of the NSS".   I called it "ComparisonIndicator"
because I believe that, absent the question of comparing a pair
of URNs for equality, the "part of the NSS" question doesn't
need a precise answer and might be a distraction.

>>> 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.
> 
> Including ServiceTarget into ServiceRequest may not be
> necessary. URN resolver appropriate for the namespace in
> question should know which server is able to cater for
> ServiceRequests of given type. For instance, if a user wants
> full metadata about an academid dissertation, the resolver
> "knows" that the national bibliography should be able to
> fulfill the request. But if the document itself is requested,
> open repository (using Fedora, DSpace or some other such
> application) is better choice.

In the language I've used, what you have just said is "for all
NIDs, it should be possible to specify the ServiceTarget as part
of the definition/ registration, thereby not requiring it to
appear in the ServiceRequest associated with a URN and probably
prohibiting it there".    If that is true, it is wonderful.  But
I'm trying to avoid a requirement to prove such statements about
"all NIDs" rather than particular NIDs or, e.g., NIDs that might
sensibly be used in the library community.

> Yes, and the number of parameters required will vary a lot
> depending on the ServiceType.

So there we agree on the abstraction and dependency on NID.  I'm
just trying to avoid a different version of the "generic
something-or-other" trap by similarly abstracting ServiceTarget
and ComparisonIndicator.   If they can be kept as part of the
NID definitions and consequently kept out of URN strings, it
will make a better, easier, and less complex world.  But I don't
see any way to demonstrate that there are no possible reasonable
namespaces for which different conventions may not be needed.
And I don't want that demonstration/proof to be in the critical
path.

>>> 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.
> 
> I am not sure it is  necessary / productive to make fragments
> reappear as ServiceRequest. As I see it, Service Requests are
> something that URN resolvers must deal with, whereas fragments
> will be processed by clients such as web browsers, both for
> URLs and URNs. At least for now I cannot see a need for a
> fragment-like Service Request, or understand properly what
> these services would be like.

See above and note that, just as I'm not sure that a generic URN
definition needs to know (or can know) what a "browser" is, I'm
not confident, generically, what a "URN resolver" is (other
than, like "browser", more handwaving).

> Using URI query for passing ServiceRequests looks like an
> attractive option with minimal technical overhead. Whether
> this kind of use of query would be confusing, and whether
> using some other mechanism would make things more clear I
> can't tell, before seeing more detailed proposal on how to
> proceed. Like Lars, I wonder if the intention is to drop just
> the word query, or the syntax as well.

Both.  Possibly we could preserve the syntax, but I think that
requires that someone make the case that the advantages of doing
so outweigh the disadvantages.  In particular, if the tuple
described above every actually needs to be present in a URN
string, I'm not sure the existing syntax works without a great
deal of confusing and error-prone clutter.

--On Thursday, June 26, 2014 10:27 +0000 "Svensson, Lars"
<[email-masked]> wrote:

>> Two URNs should be considered to be equivalent if they
>> identify the same thing.
> 
> Yes, and this depends on your definition of "thing"...

Indeed.  And I'm essentially suggesting that, in the general
case, we don't know how to define "thing" except on a
per-namespace (NID-dependent) basis.  I believe there may be
categories of namespeaces (and NIDs) that would share
thing-definitions but we haven't even begun to talk about such
categories, much less their definitions and properties.
However, I think we can demonstrate that the differences exist
just by looking at the differences in starting point, language,
and assumptions between Juha and Dale -- both of whom, I'm
convinced are acting in good faith and with a good understanding
to the problems they need to solve for their communities.

>...
>> ...because neither fragment nor query are part of the NSS.
> 
> In my eyes, that is not a strong enough argument since that is
> obvious from the syntax urn:nid:nss?query#fragment. We need an
> explicit statement that says that "for identification
> purposes, the URN ends after the last character of the NSS.
> This implies that while a generic URI parser would consider
> the two URIs urn:example:foo and urn:example:foo?bar#baz two
> different URIs and thus -- without further knowledge --
> identifying two different resources, a URN parser would treat
> them as equivalent." (Or something along those lines, which I
> cannot find in 2141bis). I also suggest that rfc 2141bis adds
> some examples with queries and fragments to §6.1.

See above and note that, if URNs are not URIs, then, if there is
such a thing as a "generic URI parser", it doesn't inherently
apply to URNs.  That, in turn, takes us back to a comment of
some months ago about a generic URI really consisting of a
method followed by method-dependent "stuff".

>...
>>  From the URN point of view fragments have nothing to do with
>> identification. National libraries and our allies assign
>> urn:nbns to resources, but typically it will be the users of
>> these resources who will add fragments to the urns when they
>> cite identified resources.
> 
> This makes the users/patrons responsible for using the correct
> fragment identifier syntax for the media type in use, which
> requires good tool support. Perhaps we need some use cases to
> illustrate how this would work.

It is more than "good tool support" unless the tools themselves
are to become de facto part of the URN definition and at least
as permanent/ persistent as the definition itself.  I don't see
that as impossible, just unlikely.

>> It is unfortunate that URI generic syntax talks about fragment
>> identifiers. We should not do the same mistake, since it is
>> very unclear what fragments could actually identify and how
>> such fragment-driven identification process would be managed
>> properly. A lay person may not see any problems here, but in
>> this respect my point of view is one of a professional who
>> has been closely involved with development and use of ISO
>> identifier standards for about 20 years.
> 
> Yes, terminology can be a PITA, but that's nothing we can
> change (modulo updating 3986).

Or separating URNs from 3986 and then defining whatever is
needed to be defined for URNs in a URN-appropriate way.  That is
exactly what "Plan B" [2] and "URNs are not URIs" are about.

>> Generally speaking, fragments can be added to URNs which
>> identify just a single manifestation of a resource and the
>> mime type of the resource allows fragment usage. There are
>> plenty of namespaces and mime types which meet these
>> requirement. The requirement for being able to use fragment
>> does not really come only from the urn:nbn community. Adding
>> fragment to the URN syntax has more to do with the needs of
>> the people who will cite resources which have already been
>> identified with URNs which then provide access to these
>> resources. IMO people will add fragments to URNs no matter
>> what the URN syntax says. But if the URN syntax says nothing
>> about fragments, then URI syntax applies, which means that
>> everyone who cites a resource identifies something (location
>> or segment or something else) within that resource by the act
>> of citing, which sounds absurd (and unmanageable) to me.
> 
> If we don't add fragments to the URN syntax, a URN with an
> added fragment simply will not be a valid URN...

Right.  And I'm trying to encourage making a distinction between
"the functionality that the urn:nbn community (and other
communities) need from "fragment" and the syntax and semantics
attached to that term by 3986 and other URL-derived documents.

 best,
    john

[2]  From my point of view, we had to move beyond "Plan A" when
trying to meet everyone's perceived needs while staying within
the boundaries established by RFC 3986 and its penumbra
(including [1] and several "URLs are sufficient" assumptions).
"Plan B" separates URNs from generic URLs, in the "URNs are not
URIs" spec or in some other way.  If that fails, then we will
need to either start thinking about how to manage a forked
specification with not-quote-compatible branches or with getting
rid of URNs in favor of field-specific UR*, possibly starting
with URSs (Uniform Resource SNAFU).

[3] Disclaimer: For better or worse, I had several interesting
conversations yesterday about Norbert Wiener's legacy (including
but not limited to "Cybernetics") and its 21st Century
implications, particularly about the importance of rigor and
precision in discussions at the man-machine boundary.  While
those discussions clearly postdate my thinking of the last
several months (and, in particular, the "URNs are not URIs" spec
and my earlier comments in this thread), they almost certainly
contribute to whatever impatience comes through in this note
about making broad generalizations about categories that cannot
be fully identified (and syntax and other rules based on those
generalizations).  As was the case two decades ago, I want to
see if we can define URNs without falling into that trap.