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

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 27 Jun 2014 15:39:04 +0000

John,

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

Well, of course they are. I think we get bogged down with the question, if URNs are a subclass of URIs or not. I try to argue that URNs _should_ be a subclass of URIs for the simple reason that it allows me to use a URN in all places where a URI is expected, e. g. as an XML namespace identifier, or in a SemWeb/LinkedData setting, where identifiers for entities are requested to be URIs. This is not only a concern about breaking backward compatibility, but also a marketing issue: One of our selling points when we try to convince people to use URNs is exactly the point that they are URIs, too and that all the usages mentioned above are open to them.

>  -- 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.
> 
> >>> 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".
> >
> > 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),

This seems to be the place where we need to find a common view on things. My reading is that URIs (as defined by 3986) are _always_ identifiers and that _some_ URIs (depending on their scheme) are also locators. To the "pure identifiers" I count e. g. geo:, xcon: and crid: (and urn:), while e. g. http:, ftp: and smtp: would be locators as well. So in my view, we cannot generalise URLs into URIs, which would allow us to keep URNs as a subclass of 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.

Yes, it is still very obvious that fragments (and queries) come from http. The question is if we can generalise them to be used in URNs, too.

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

Currently, it's just an editor's draft, so you are perfectly right that it is in no way authoritative.
 
> >...
> > 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.

We _could_ make statements of how a spec-conforming user agent has to behave.

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

I think it has been said on this list before (and now I start to understand that...) that one of the flaws in 3986 is that it is not only about syntax, but also about semantics. It would have been much easier if 3986 had only specified that fragments are allowed and where they fit in the syntax, and left it to individual URI schemas to define the semantics. The same applies to queries.

[...]

> >>> In the above, a ServiceRequest is, again conceptually, a
> >>> tuple of
> >>>
> >>>     ServiceType ComparisonIndicator ServiceTarget
> >>> ReequestParameters...
> >>>
> >>> ServiceType is nominally some sort of keyword.
> >
> > 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.

Does this imply that we should not try to update 2483 at all but instead make the service description (keywords etc.) part of the NID registration process?

> >>> ComparisonIndicator tells something trying to compare a pair
> >>> of URNs for identity whether that particular ServiceRequest
> >>> counts or should be ignored.
> >
> > I am not sure I understand the need for ComparisonIndicator.
> 
> 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.

I think I understand what you are aiming at, but do you think you could provide an example or two just for clarity? (No, I won't nail you down on syntax...).

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

Right. URNs are too diverse that we could specify something for all of them. Another argument for the NID level of specification.

> >>> And RequestParameters are
> >>> anything the ServiceType definition says they are.
> >
> > 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.

OK.

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

My definition is that a URN resolver is an application that given a URN and a set of service requests returns the object, metadata or whatever that is associated with the URN as specified by the service requests.

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

As said, to me there is value in keeping URNs as a subclass of URIs.
 
> --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.

We can define behaviour for conforming agents, just as other specifications do.

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

Since "URNs are not URIs" requests an update of 3986 anyway, why can't we try to move the _semantics_ of fragment out of it and into the http specification instead?

> >> 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
> 
> 
> [1] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids
> 
> [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.
>

---

From: John C Klensin <[email-masked]>
Date: Sun, 29 Jun 2014 03:45:56 -0400

--On Friday, June 27, 2014 15:39 +0000 "Svensson, Lars"
<[email-masked]> wrote:

> John,
> 
>> 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
>> 
> Well, of course they are.

Unless I've misunderstood a number of remarks, your "of course"
view is not universally shared.

> I think we get bogged down with the
> question, if URNs are a subclass of URIs or not. I try to
> argue that URNs _should_ be a subclass of URIs for the simple
> reason that it allows me to use a URN in all places where a
> URI is expected, e. g. as an XML namespace identifier, or in a
> SemWeb/LinkedData setting, where identifiers for entities are
> requested to be URIs. This is not only a concern about
> breaking backward compatibility, but also a marketing issue:
> One of our selling points when we try to convince people to
> use URNs is exactly the point that they are URIs, too and that
> all the usages mentioned above are open to them.

First, I think "a URN can be used in all places where a URI is
expected" is, operationally, something of a fantasy.  The
problem is that we have URNs for which "resolution" is
meaningless and so is any "use" other than "ok, the syntax works
and nothing will break in parsing"  (the latter argument would
have been stronger if we had adopted the requirement that URIs
be clearly delimited, or at least clearly (and unambiguously and
consistently) terminated, in running text).   Arguably a
statement like "a URI can be used anywhere a URI can be used",
however tautological-sounding, is a fantasy too.  The difficulty
is that we don't have a URI syntax definition that is ultimately:

   Method: <stuff> <single-terminating-delimiter>

Instead, we have a lot of Method-dependent stuff that affects
how the rest of the URI (whatever that means) is parsed and
interpreted.  If some program doesn't understand the Method in
context, all it can do is parse the URI away from other text
and, I believe in principle, might not even be able to do that.
Knowing that it can break the URI into enough pieces to pass the
components to a generic API really just kicks the proverbial can
down the road -- that API must still have method-dependent
actions to make any use of the material or it needs a good way
to back out and deliver a failure message to the user -- one
that should really be better than "Huh?" but often isn't.

All of that said, it would be perfectly reasonable to not go as
far as "URNs are not URIs" but instead rip all of the semantics
and maybe some of the syntax restrictions out of 3986.   As I
said in earlier notes and, to some degree, in the document, it
would be a lot of work to pick 3986 apart and would be hard to
get consensus because that sort of revision would require
agreement across the whole URI community.  I'm not willing to do
that work (even if I had time, which I don't), in part because I
see other developments making it irrelevant.  And I think that
holding URNs hostage until it is done guarantees a fork or
worse.   But, if you want to take it on, go to it.

>> 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),
> 
> This seems to be the place where we need to find a common view
> on things. My reading is that URIs (as defined by 3986) are
> _always_ identifiers and that _some_ URIs (depending on their
> scheme) are also locators. To the "pure identifiers" I count
> e. g. geo:, xcon: and crid: (and urn:), while e. g. http:,
> ftp: and smtp: would be locators as well. So in my view, we
> cannot generalise URLs into URIs, which would allow us to keep
> URNs as a subclass of URIs.

As I've tried to say before, I think that a philosophical debate
about the precise proper usage of the term "identifier" is
extremely interesting but doesn't lead us anywhere on which
agreement is likely in the foreseeable future.  That makes one
important question whether we are willing to delay any progress
on URNs until we do agree.

However, "we cannot generalise URLs into URIs,..." is a
statement with which I've come to agree.   RFC 3986 is precisely
a generalization of URLs into URI.  Yet another view of it is
that it attempted the impossible (or contradictory) and failed.
So where does that leave us?

> Yes, it is still very obvious that fragments (and queries)
> come from http. The question is if we can generalise them to
> be used in URNs, too.

I think the question is a little different.  I'd like to see us
start by either figuring out what functionality we need across
the whole family of potential URNs, at least temporarily
avoiding the terms "fragment" and "query" because they carry
both syntactic and semantic baggage with them, and only then
asking how closely we can adapt those answers to the general URI
framework.  Maybe things could have worked out differently,
especially if 3986 were better designed and written, but, today,
"generalise them to
> be used in URNs" has too many aspects of a Procrustean
solution.

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

Yes.  But the IETF (as distinct from, e.g., W3C) generally
avoids making statements about user agent behavior.  More
important, because, while all URLs must be resolvable in at
least some general sense, we've seen several examples of URNs
that are not resolvable or intended to be resolved.  A statement
about user agent conformity that would be broad enough to cover
all of those cases would probably not be useful.  Or perhaps I
don't understand what you have in mind.

>...
> I think it has been said on this list before (and now I start
> to understand that...) that one of the flaws in 3986 is that
> it is not only about syntax, but also about semantics. It
> would have been much easier if 3986 had only specified that
> fragments are allowed and where they fit in the syntax, and
> left it to individual URI schemas to define the semantics. The
> same applies to queries.

Yes, see above.

>> > 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.
> 
> Does this imply that we should not try to update 2483 at all
> but instead make the service description (keywords etc.) part
> of the NID registration process?

Two separate questions.  First, 2483 (and the relevant
DDDS-specific specs) are mostly irrelevant to this discussion
and have been overtaken by events, especially the event of
indicator-style (never resolved) URNs.  I presume it is not an
accident that work on them was never part of the URNbis charter.
And, yes, I think any service descriptions have to be part of
the registration process... and that 3406 already goes a
significant distance in that direction.

>> >>> 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.
> 
> I think I understand what you are aiming at, but do you think
> you could provide an example or two just for clarity? (No, I
> won't nail you down on syntax...).

For "ComparisonIndicator", I'm worried about, and trying to
evade, the argument about whether Service Requests are, or are
not, enough part of the URN to effect whether or not two
URN-strings compare equal.  So (and again with the understanding
that there are lots of ways to do with syntax and defaults,
suppose we defined two categories of Service Requests, one of
which was considered integral to the URN (i.e., that, if a
particular request appeared in one URN-string but not another,
the two URNs would be treated as not equal) and one that was
not.  Now, suppose (I hope you can render UTF-8 because, for
this example, I need to choose delimiters that are not
complicated by 3986 -- if you cannot, the two funny characters
below are U+2191, upwards arrow, and U+2193, downwards arrow,
respectively) that, rather than using "?" to introduce both
categories on the assumption that all Service Requests are
queries, we had 

   ↑ServiceRequest
denoting the integral ones and
   ↓ServiceRequst 
denoting the non-integral ones

Then 
   urn:xxx:string↑foo  and urn:xxx:string↑bar would compare
"not equal"
but
   urn:xxx:string↓foo  and urn:xxx:string↓bar would be
considered equal URNs.

If my interpretation of Juha's comments is correct and he is
correct that we would never need the first case ("↑") than
that would be fine -- we'd just never see that delimiter and
everyone would be happy.  But I want to avoid getting a
correctness proof on "Service Requests are never to be
considered part of the NSS" in our critical path if we possibly
can.  Something like the above may be a way to make that
separation.

>> 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.
> 
> Right. URNs are too diverse that we could specify something
> for all of them. Another argument for the NID level of
> specification.

And another argument for considering any work based on RFC 2483
or the DDDS work to be about techniques available for use in
selected URNs (with the selection occurring as part of NID
specification) rather than as generic URN functions.

>...
>> 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).
> 
> My definition is that a URN resolver is an application that
> given a URN and a set of service requests returns the object,
> metadata or whatever that is associated with the URN as
> specified by the service requests.

Ok, Accepting that definition for the moment, what happens when
a URN resolver is given an indicator-only URN (with or without
service requests).  Those indicators (see Peter's XMPP example)
don't have "objects, metadata, or whatever", they just exist or
don't.  I imagine we could come up with an elaborate definition
that would cause them to have values, even if the values were
self-identity, but I'm not yet persuaded that such kludges are
worth the costs.

>> 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.
> 
> Since "URNs are not URIs" requests an update of 3986 anyway,
> why can't we try to move the _semantics_ of fragment out of it
> and into the http specification instead?

I'd be delighted to.  But see the "no time" comments above and
note that the integrity of 3986 is under attack from the URL
side as well and that we would do ourselves no favors by trying
to change it in divergent directions and without coordination.

Put differently, I believe that tearing down 3986 and clarifying
its boundaries would, in a more perfect world, be exactly the
right thing to do.  In our present world, I'd rather get the URN
specs moving forward and finished.

best,
   john