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

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

John,

> From: John C Klensin [mailto:[email-masked]]
> Sent: Sunday, June 29, 2014 9:46 AM
> To: Svensson, Lars; Juha Hakala; Dale R. Worley
> Cc: [email-masked]
> Subject: RE: Re: [urn] urn:ietf:rfc
> 
> 
> 
> --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
> >>
> >>  -- try to accommodate all of those who think URNs are
> >> 	necessary, i.e., that they are distinct from URLs.
> >
> > Well, of course they are.
> 
> Unless I've misunderstood a number of remarks, your "of course"
> view is not universally shared.

My reading of the discussion is rather that we (== "the community") don't differ on the necessity of URNs. To me the big question is if we can say URI==URL. I say it's not. There are names and there are locators. In some settings, it makes sense to use a locator as a name (and sometimes it doesn't). In my eyes that doesn't make all URIs URLs (but perhaps I live in a parallel universe...).

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

True.

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

Yes, but without the method-dependent stuff, we wouldn't need different methods at all, would we? That said, I start to understand your concerns about the (non-)usefulness of a generic URI syntax.

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

> 
> >
> >> 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)
> >...
> 
> > 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.
> >
> > We _could_ make statements of how a spec-conforming user agent
> > has to behave.
> 
> 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.

This distinction between IETF and W3C wasn't clear to me. My intention was really to specify the behavior of a conforming user agent/service. I envisioned something along the lines of "if an agent sends a service request with request method foo without specifying one of the parameters bla, fasel or blupp, the service MUST discard the request and send an appropriate error message", or "a conforming user agent SHOULD display the URN in its canonical form (whatever that might be...)", or "a user agent MUST strip the ramba-zamba part (aka fragment identifier) of the URN before sending a service request and MAY do something fancy with the ramba-zamba after it has received data from the server".

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

More below.

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

Juha will know this better than I do, but I have vague memories that we pretty early in the process realised that it was a mistake not to consider 2483 as well. If you need a reference I can dig through my mail archives.

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

OK, that's fine with me.

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

Could an example be a request for resource metadata? The metadata is not the resource, so those should not be equal.

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

I agree that we should keep the semantics as flexible as possible. The downside would be that someone who implements services for several NIDs has an increased burden since they need to consider many different service request vocabularies. If we can agree on a syntax it should be possible to build a parser that extracts the NID and can pass the parsed service requests to the correct service strategy. (But I start to think implementation here...).

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

Yes, it seems the two of us agree on that. 

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

I guess the resolver would have some default behaviour... The worst case being "I don't know how to handle a URN of type urn:example:foo". I think it's clear by now that resolvers are NID-specific.

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

I wasn't aware of that. Can you provide a pointer to that discussion? If there is common ground regarding terminology, fuzz (aka "query") and ramba-zamba (aka "fragment") perhaps there is something coming up.

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

It's really Scylla or Charybdis, isn't it? We can either fork URNs from URIs or risk that URNs are forked into something else. I really don't know what's worse.

Cheers,

Lars