Subject: [urn] Choice matrix

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Thu, 24 Jul 2014 18:16:23 -0400

Hi,

Reading through John's slides for tomorrow, something clicked in my head 
(errr, hope it wasn't unhealthy ;-) ) and it seemed to me to be useful 
to think of the discussion in terms of a matrix of choices:  whether or 
not URN syntax is divorced from URI syntax; whether or not "?" and "#" 
syntax elements are defined for URNs.

I deliberately stated those in terms of functional choices, not 
semantically-laden options.

1-1:  URN syntax IS divorced from URI syntax; "?" and "#" ARE defined 
for URNs
	+ Avoids the problem that existing URI fragment & query semantics don't 
fit for URNs
	+ Can (IMO, should) define "?" and "#" using terms OTHER than fragment 
and query, and make them as generally applicable to URNs (as defined by 
the IETF standard) as possible
	- contributes to demise of the current standard for URI syntax
	? problems with parsers?

0-1:  URN syntax is NOT divorced from URI syntax; "?" and "#" ARE 
defined for URNs
	- Existing URI fragment & query semantics don't fit for URNs; 
workarounds include per-namespace rules, etc, but largely unenforceable

1-0:  URN syntax IS divorced from URI syntax; "?" and "#" are NOT 
defined for URNs
	? Avoids potential future clashes of syntax between generic URI syntax 
and URNs
	- seems kind of pointless

0-0:  URN syntax is NOT divorced from URI syntax; "?" and "#" are NOT 
defined for URNs
	? status quo.

Other thoughts on +/-?

Leslie.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jul 2014 00:26:47 +0200

On 2014-07-25 00:16, Leslie Daigle (TCE) wrote:
>      + Avoids the problem that existing URI fragment & query semantics
> don't fit for URNs
>      + Can (IMO, should) define "?" and "#" using terms OTHER than
> fragment and query, and make them as generally applicable to URNs (as
> defined by the IETF standard) as possible
 > ...

Can you elaborate on what's the problem with the RFC 3986 semantics for 
queries? (not fragments)???

Best regards, Julian

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Fri, 25 Jul 2014 10:29:38 -0400

(Keenly aware that this is a slippery slope, and trying not to rehash 
every single previous argument):

[Julian quoted me and said:]
 > queries? (not fragments)???

RFC2141 set aside the use of "?" because we could not figure out how 
queries (in the URI standard) made sense against _all_ URNs/URN namespaces.

And, if they don't make sense for all URNs, it's hard to see how to 
enable them in the URN-wide standard.

Leslie.

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 25 Jul 2014 14:31:43 +0000

> enable them in the URN-wide standard.

That's why I think it would be best to specify queries on a per-NID-basis.

/Lars

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jul 2014 16:36:10 +0200

> enable them in the URN-wide standard.

I understand that, but it's not a problem of RFC 3986, right?

Best regards, Julian

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Fri, 25 Jul 2014 10:47:11 -0400

I think we agree -- my aim was not to criticize RFC3986, but rather talk 
about the options for URN specification whether it remained part of the 
URI (syntax, semantics) spec or not.  That's not (intended to be) a 
value judgement of the URI spec.

Leslie.

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Jul 2014 10:47:59 -0400

--On Friday, 25 July, 2014 16:36 +0200 Julian Reschke
<[email-masked]> wrote:

>> And, if they don't make sense for all URNs, it's hard to see
>> how to enable them in the URN-wide standard.
> 

I believe that is correct.  I believe the query-related problems
with 3986 arise only if one pushes beyond what 3886 is specific
about and if some things that you apparently believe are totally
optional are, in fact, requirements if one goes down a
particular path, e.g., one cannot pick and choose rungs on the
comparison ladder but more conceptually start from the bottom
and work one's way up.  I believe 3986 clearly allows adding
rungs at the top of the ladder, but not reinterpreting the ones
that are there.  I gather you and Martin read it differently.  

I suggest that, if 3986 allows contradictory good-faith and
careful readings, that is a problem with 3986 but not a problem
for URNs.

However, were URNs (or other types of URIs) to move away from
3986 for other reasons, they might be able to avoid taking those
ambiguities, and some operations that are apparently not
optional (another difference in reading) but obviously
inapplicable to many cases, along.   The latter would simplify
fully-conforming implementations although, if I correctly
understand the implications of some of Martin's remarks, either
far more of 3986 is discretionary than I believe to be the case
or fully-conforming implementations are rare.

    john

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jul 2014 17:02:49 +0200

> with 3986 arise only if one pushes beyond what 3886 is specific

...pushes beyond what it actually says...

> that are there.  I gather you and Martin read it differently.

6.2.3 specifically allows scheme-specific normalization. This is your 
extension point.

> careful readings, that is a problem with 3986 but not a problem

It would be a problem of 3986. I personally think it's clear enough, but 
if some specific prose gives you a hard time then we should raie an 
erratum instead of taking a drastic step.

> or fully-conforming implementations are rare.

You keep ignoring the downsides, as far as I can tell.

If URNs are declared not to be URIs, you can't use them anymore in 
places that accept URIs, right?

Best regards, Julian

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Fri, 25 Jul 2014 11:13:40 -0400

To be very clear:  "URN" is the "scheme" in the context of the URI 
syntax.  That is, something that is "scheme definable" in the URI spec 
must be defined for all URNs.

To implement something on a per-NID basis is hard to police (opinion), 
and I believe is not consistent with the URI spec.

Leslie.

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Jul 2014 11:14:24 -0400

--On Friday, 25 July, 2014 10:47 -0400 "Leslie Daigle (TCE)"
<[email-masked]> wrote:

> I think we agree -- my aim was not to criticize RFC3986, but
> rather talk about the options for URN specification whether it
> remained part of the URI (syntax, semantics) spec or not.
> That's not (intended to be) a value judgement of the URI spec.

Let me add a personal note to Leslie's comment.   The separation
draft (which others convinced me to call "URNs are not URIs")
was never intended as a value judgment of the URI spec.  It was
just the result of conclusions by several people (and maybe even
the WG), reached before I did, that the entanglements with 3987
were creating complications and impediments with moving forward
with URN work.   The biggest assumed entanglement was that 3986
was basically a URL spec that had been generalized for other
types of URIs but not generalized enough to accommodate URNs
which, advantageous syntax similarities aside, were a different
sort of creature.

It is no secret that I've acquired an aesthetic dislike of the
way 3986 is constructed as I've been working on this URN effort.
But that is my problem and, unless pressed, I don't even want to
spend time discussing it.

A different version of the questions posed by Andy and Leslie is
that, if one says "different kind of creature" and "don't be
completely dependent on 3986", whether one can preserve enough
of the 3986 syntax to allow generic, really scheme-independent,
URI parsers to keep working regardless of what more specific
changes are made for URNs.  I'm pretty sure the answer to that
question is "yes" and that the URN WG shouldn't do anything that
turns it to "no" (whether in conformance to 3986 or not).  

So, if potential incompatibility with generic URI parsers (one
that, among other things, do not make assumptions based on HTTP
practices) is the concern, we really have no disagreement that I
can see.

On the other hand, if the issue is about the legitimacy of URNs
or whether they are (or get to be) a different kind of creature
from traditional HTTP-URLs, then we have a different sort of
disagreement.  I don't know how to make progress on that one.

     john

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jul 2014 17:28:42 +0200

> turns it to "no" (whether in conformance to 3986 or not).

But if you continue to feed the non-URI-URNs into code written based on 
RFCs 2396 and 3986, what's the point in pretending they are not URIs????

> disagreement.  I don't know how to make progress on that one.

I haven't seen anybody saying URNs aren't legitimate here. Nor does RFC 
3986 does say that.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jul 2014 17:29:46 +0200

> and I believe is not consistent with the URI spec.

I agree that it's tricky to specify, but I don't see RFC 3986 forbidding it.

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Jul 2014 11:36:23 -0400

--On Friday, 25 July, 2014 17:28 +0200 Julian Reschke
<[email-masked]> wrote:

>> A different version of the questions posed by Andy and Leslie
>> is that, if one says "different kind of creature" and "don't
>> be completely dependent on 3986", whether one can preserve
>> enough of the 3986 syntax to allow generic, really
>> scheme-independent, URI parsers to keep working regardless of
>> what more specific changes are made for URNs.  I'm pretty
>> sure the answer to that question is "yes" and that the URN WG
>> shouldn't do anything that turns it to "no" (whether in
>> conformance to 3986 or not). ...
> 
> But if you continue to feed the non-URI-URNs into code written
> based on RFCs 2396 and 3986, what's the point in pretending
> they are not URIs????

Leslie's note illustrates why we wanted to unbind URNs from 3986
(whether they are, or are not, URNs is actually not relevant).
She believes that 3986 doesn't allow query syntax (or not) on a
per-NID basis.  You disagree.  The draft was motivated by trying
to get unstuck from that type of argument in order to make
progress on URNs.  

I'll be happy to discuss the legitimacy issues and the reasons
I'm concerned about them with you f2f.

    john

p.s. I'm almost certainly offline between now and when the WG
session starts.

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 25 Jul 2014 18:40:41 +0000

> must be defined for all URNs.

Is there anything in 3986 that prevents a scheme specification to delegate specific parts of the syntax to more specialised specifications? I have read and re-read 3986 but can't find anything.

> and I believe is not consistent with the URI spec.

The question is if we take the position that things that are not explicitly allowed are forbidden, or if it's not explicitly forbidden, it's allowed.

/Lars

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jul 2014 22:10:19 +0200

> Is there anything in 3986 that prevents a scheme specification to delegate specific parts of the syntax to more specialised specifications? I have read and re-read 3986 but can't find anything.

Nope.

Best regards, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 27 Jul 2014 16:35:11 +0900

> I agree that it's tricky to specify, but I don't see RFC 3986 forbidding

I actually think it's utterly consistent with RFC 3986. RFC 3986 only 
says that it's "scheme definable". This means that a scheme can define 
what it wants.

The 'mailto' scheme uses a definition that's consistent across all 
'mailto' URIs. A query part such as 'subject=Greeting' or 'body=Hello' 
means exactly the same on every 'mailto' URI. 
(http://tools.ietf.org/html/rfc6068#section-6.1)

The 'http' scheme leaves everything open and completely variable. 
http://example.com?q=foo can e.g. mean something different every 
different hour of the day (not recommended but allowed). There is 
definitely no guarantee that 'q=foo' mean the same thing on 
http://example.com and on http://example.org, quite to the contrary.

If the URN spec decides to leave things to NIDs, that would be in the 
middle of the above two extremes. There's no possibility for that to be 
disallowed.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 27 Jul 2014 16:50:44 +0900

> Is there anything in 3986 that prevents a scheme specification to delegate specific parts of the syntax to more specialised specifications? I have read and re-read 3986 but can't find anything.

Nor can I. And I gave examples of widely deployed schemes on both extremes.

> The question is if we take the position that things that are not explicitly allowed are forbidden, or if it's not explicitly forbidden, it's allowed.

This isn't something that the URN WG should have to worry about. It 
should be clear (or derivable with some common sense) from the spec 
that's being used.

As an example, syntax productions are usually "if not allowed, then 
forbidden". So trying to claim that urn:NID:¶§©ØôÇ is allowed by RFC 
3986 would be clearly wrong.

As another example, usage is generally wide open. RFC 3986 delegates 
specifics of the query part to each scheme because it assumes that there 
are many possible uses for schemes and queries, and it would be 
completely foolish to restrict them.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 27 Jul 2014 17:30:03 +0900

Hello John,

On 2014/07/25 23:47, John C Klensin wrote:

> I believe the query-related problems

Yes indeed. Here is some text taken from RFC 3986:

Second paragraph of Section 6, Normalization and Comparison 
(http://tools.ietf.org/html/rfc3986#section-6):

    URI comparison is performed for some particular purpose.  Protocols
    or implementations that compare URIs for different purposes will
    often be subject to differing design trade-offs in regards to how
    much effort should be spent in reducing aliased identifiers.  This
    section describes various methods that may be used to compare URIs,
    the trade-offs between them, and the types of applications that might
    use them.

The key phrase is "*describes* various methods that *may* be used". So 
it's essentially "here's some things you may want to consider, and why".

Then we have at the start of Section 6.2, Comparison Ladder 
(http://tools.ietf.org/html/rfc3986#section-6.2):

    A variety of methods are used in practice to test URI equivalence.
    These methods fall into a range, distinguished by the amount of
    processing required and the degree to which the probability of false
    negatives is reduced.  As noted above, false negatives cannot be
    eliminated.  In practice, their probability can be reduced, but this
    reduction requires more processing and is not cost-effective for all
    applications.

    If this range of comparison practices is considered as a ladder, the
    following discussion will climb the ladder, starting with practices
    that are cheap but have a relatively higher chance of producing false
    negatives, and proceeding to those that have higher computational
    cost and lower risk of false negatives.

For me at least, the phrase "*If* this range of comparison practices is 
*considered* as a ladder" clearly indicates that the ladder here is an 
expositionary device, chosen to bring a bit of order into the range of 
choices, rather than some pre-/post-condition structure.

> careful readings, that is a problem with 3986 but not a problem

Fully agreed. If you have any textual fixes, please submit them as errata.

> ambiguities,

If whatever you create is to be used in places where URIs are used, then 
you can only avoid part of these ambiguities.

As I already mentioned, URNs *are* used as XML namespaces, and XML 
namespaces *are* compared character-by-character, so even if the URN 
spec says that
urn:example:foo&a=x&b=y and urn:example:foo&b=y&a=x are always the same, 
using such an URN as an XML namespace would still have to make sure that 
everybody only use one of the two variants.

On the other hand, even in the case that you wanted to insist that
urn:example:foo&a=x&b=y and urn:example:foo&b=y&a=x are two 
fundamentally different URNs, there might still be search engines that 
decide that they treat them as the same because for other schemes, that 
will reduce costly re-fetching of one and the same resource at the cost 
of an occasionally missed resource, and the search engine, at any 
specific point in time, may consider the cost of dealing with UNRs too high.

> and some operations that are apparently not
> inapplicable to many cases, along.

I guess you are referring to removing /./ and /../ and the like. If 
something is mandatory but inapplicable, my guess is that it is an 
identity operation, which would be *very* easy to implement.

I have to admit that Section 5, Reference Resolution, which deals with 
/./ and /../, isn't the part of RFC 3986 that I'm most familiar with, 
but my strong guess would be that as long as URNs don't allow '/', we 
are indeed talking about an identity operation.

> The latter would simplify

Yes indeed.

> or fully-conforming implementations are rare.

In a sense, that's also true. There are many parts of the spec, and what 
an implementation needs to do depends on what operation it is applying. 
That can be comparet to implementations of SMTP; some implementations 
will only implement the client side, others only the server side.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 27 Jul 2014 17:46:51 +0900

Hello John, others,

> which, advantageous syntax similarities aside, were a different

My impression so far is that this is mostly based on misunderstandings. 
Some of these misunderstandings may be relatively easy to make, others 
are very difficult to understand (such as generalizing from a single 
example).

> spend time discussing it.

[Thanks for mentioning this. It was my impression, too, and I was 
debating with myself whether I should bring it up or not, but given that 
you have mentioned it now, I will do my best to not touch this point any 
further.]

> On the other hand, if the issue is about the legitimacy of URNs

There is no question that RFC 3986 considers URNs legitimate. Otherwise, 
it wouldn't give an example, or would it?

> from traditional HTTP-URLs,

Of course they are different from http: URIs. Mailto URIs are also 
different from http: URIs. And the same for all the other many 
registered (and unregistered) schemes. But they are all URIs, and it 
makes a lot of sense to keep them as URIs.

> then we have a different sort of

I don't think we have a disagreement, or where we might have a 
disagreement (e.g. with respect to where exactly to use http: URIs vs. 
URNs), it's not relevant for the technical work we are chartered to do.

Regards,   Martin.

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Jul 2014 05:55:44 -0400

Summary of my preferences:

1. URN syntax IS divorced from the syntax of other URIs, or at least RFC 
3986 syntax.   Though we still call URNs a kind of URI, and we still try 
to make URNs look more-or-less like URLs modulo the extra ":" after the NID.

2. Define a new "extended URN" syntax using neither "?" nor "#" for 
"facets" of URNs,

3. "?" and "#" and what follows aren't part of the URN.  However, the 
behavior of "?" and "#" when appended to URNs is defined.

Goals:

1.  Do not overload "?" or "#" with new behaviors in the URN context.   
Retain the familiar, most-visible behavior of these.

2.  Relieve the pressure to overload "?" and "#" with new syntax for facets.

3.  Retain the ability to use "?" and "#" with resources referenced by 
URNs that resolve to URLs, in a way compatible with that used when the 
URLs are accessed directly.    (Once the client resolves a URN to a URL, 
it handles "?" and "#" in the context of that URL exactly as it does for 
any other URL.)

4.  Avoid, or at least minimize, the need for special-cases in client 
software and protocol handlers that deal with URNs.   (This is the 
reason for goal #3)

A requirement for special-case handling of URNs as a class, as opposed 
to other URIs, is tolerable when necessary.   Requirements for 
special-case handling of specific URN namespaces should be steadfastly 
avoided because this makes it difficult for client software to handle 
all URNs in a generic fashion - it makes it much more likely that client 
software would only handle a small subset of URNs, and thus harms 
interoperability.   (However, namespaces that believe that they control 
all resolution of their particular URNs might still get what they want, 
if they adhere to some implementation constraints...see below.)

(Of the above, I regard #4 as the most important.   But #3 is important 
to implement #4 unless you just want to say that "#" and "?" can't be 
used with URNs at all.)

Details:

  * Redefine URN syntax in an RFC that updates RFC 3986.

    Reasons:
      o RFC 3986 seems to be a large part of the confusion regarding
        applicability of # and ? to URNs,
      o we need to extend URN syntax to accommodate additional
        requirements, and
      o revising RFC 3896 is the task of Sisyphus.

  * reserve "/" (I think that's the best choice) to introduce new URN
    "facets" using a syntax of the form

    extended-URN = URN *( "/" type = value )

    where type and value are tokens that don't contain any characters
    that would confuse a URI parser.

      o Define an IANA registry for types and interpretation of
        associated values.   The registry defines for each type whether
        value is base64-encoded, and whether that type can appear more
        than once with different values.

      o Define a canonical ordering for /type=value suffixes so that
        comparison of extended URNs with facets in canonical order
        sort-of works with things that use existing URN comparison
        rules.   Mandate use of this form of extended URNs in most
        circumstances where URNs are used as references.

      o Decide whether extended URNs must themselves qualify as URNs -
        i.e. whether the binding between an extended URN and the
        resource (version, section, whatever) named by the extended URN
        must itself remain persistent.   Perhaps reserve a portion of
        "type" namespace (say, all types beginning with "-") for facets
        that break binding persistence.

      o Then invite other standards-making bodies with appropriate
        expertise to define and register extended URN facets that meet
        their requirements.   They can, of course, define fragment-like
        facets or query-like facets (presumably defined better than the
        traditional web facilities) using this syntax.   IMO, IETF's
        role in reviewing such facets should mostly be to make sure that
        the syntax doesn't break things, client software can parse,
        compare, and generally deal with all URNs in a uniform manner
        (special cases are bad), and that the facet is defined in such a
        way that it doesn't break persistence (unless its type name
        indicates that it does).

  * "?" and "#" are reserved specifically for use in the context of
    referenced resources in a manner consistent with their use in
    external links on the web:

      o "?" is reserved for queries submitted to the named resource (NOT
        a resolution server) using the URL and protocol used to actually
        access the resource

        So if urn:foo:bar resolves to
        http://some.domain.example.com/random/path
        then urn:foo:bar?THING is interpreted as
        http://some.domain.example.com/random/path?THING

        Strictly speaking, the "?" and what follows are NOT considered
        part of the URN (because persistence is not assured), but they
        MAY appear with a URN.

        If the WG prefers, instead of describing "?" in vague terms of
        protocol, define this as a purely syntatic convention for
        mapping from URNs to URLs.   So if a URN maps to a URL that uses
        "?" for something other than a query, it will still work with
        this convention.   That has the nice attribute that client
        software doesn't have to care what "?" actually means in the
        context of URNs - it only evaluates "?" and what follows in the
        context of any URL that a URN resolves to.

          + /Note that with this behavior, nothing stops someone from
            using "?" with a URN to mean anything they want it to mean,
            as long as the resolution for that URN works in such a way
            that IF the resource is network-accessible, then whatever
            resource(s) the URN maps to are described with URLs, for
            which the "?" and what follows do what whoever used "?" with
            that URN wants it to do. //So in the case where a URN
            maintainer (or NID maintainer) believes it controls all
            resolution of resources of a URN or group of URNs, the
            maintainer can effectively make "?" mean whatever it wants
            it to mean, e.g. by arranging for all such URNs to be
            resolved to HTTP servers that interpret "?" the way the URN
            maintainer wants.   I'm not sure that's entirely a Good
            Thing, as URNs should retain their meaning independently of
            any resolution service.   But this might be politically
            convenient for parties that really want to use "?" in some
            way, and I've already said that "?" and what follows aren't
            actually part of the URN./

        Applicability of "?" to resources that will never be
        network-accessible is undefined, but even for those resources
        "?" MUST NOT be defined in such a way as to change the meaning
        of the URN or behavior of a resolution service.

      o "#" is reserved to identify fragments within a referenced
        resource, according to however fragments are identified by the
        content-type of the referenced resource.

        So if urn:foo:bar resolves to
        http://some.domain.example.com/random/file.html
        then urn:foo:bar#zot resolves to
        http://some.domain.example.com/random/file.html#zot

        Strictly speaking, the "#" and what follows are NOT considered
        part of the URN (because persistence is not assured), but they
        MAY appear with a URN.

        (if you want, make this a purely syntatic convention)

          + Note that with this behavior, nothing stops a URN maintainer
            from defining "#" to work however it wants "#" to work, as
            long as such URNs always resolve to zero or more
            content-types that interpret the "fragment" portion of the
            resolved URL in the way the URN maintainer wants them to be
            interpreted.  What the URN maintainer cannot do is redefine
            the meaning of fragments for existing content-types.

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Jul 2014 06:13:05 -0400

> says that it's "scheme definable". This means that a scheme can define 
Yes, 3986 allows a scheme to define what it wants.   The reason that "?" 
should not have a namespace-specific meaning is not because 3986 
prohibits it.

Some reasons that "?" should not have a namespace-specific meaning are:

- This would require every client that tries to generically handle URNs 
to special-case handling of specific namespaces and the interpretation 
of "?" within each namespace

- This would, for namespaces that defined "?" differently, preclude 
passing query strings to URNs that resolved to URLs that could accept 
queries.

- It would lead to really odd behavior.    if A and B were both names 
for resource X, but A and B were in different namespaces, A?Y and B?Y 
might produce different results.   I don't think this is actually 
prohibited by any of the URN-related specifications, but it violates 
common sense, and makes it potentially problematic to assign new names 
to previously named resources even when there are good reasons to do so.

Keith

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Wed, 30 Jul 2014 10:53:41 -0400

Coming back to this before following up a later message -- I believe 
we're largely saying the same thing, but my opinion (annotated as such!) 
is that per-NID specification is not only tricky, it's likely to lead to 
heartbreak.

Leslie.

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Wed, 30 Jul 2014 11:11:23 -0400

Getting beyond the meta, I'd like to see actual proposals for how to 
handle facets (whether using the "?" and "#" or not) in a way that works 
consistently across all persistent identifiers.

To further remove noise from that discussion, I think having the 
discussion in the abstract -- e.g., for a new [UR]identifier, as Joe 
Hildebrand suggested at the meeting last week -- might be helpful.

Thumbwrestling about interpretations of RFC3986 is distracting from the 
hard problem, IMO.

I don't have a proposal to kick off the discussion, as I am a 
self-admitted skeptic :-)

A few comments on Keith's proposals:

> 2. Define a new "extended URN" syntax using neither "?" nor "#" for

IMO, 2 is possible iff it's an entirely new identifier scheme (because 
there are no other reserve characters for URNs).  That observation may 
be consistent with Keith's thinking.

> behavior of "?" and "#" when appended to URNs is defined.

Isn't this how they were originally defined for URIs?

> Retain the familiar, most-visible behavior of these.

Yes.  If possible.
> it handles "?" and "#" in the context of that URL exactly as it does for

Given that URNs don't consistently resolve to particular URLs, for a 
single URN, let alone across all URN namespaces, how would this work?

Leslie.

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Jul 2014 04:58:21 -0400

On 07/30/2014 11:11 AM, Leslie Daigle (TCE) wrote:
> handle facets (whether using the "?" and "#" or not) in a way that 
> works consistently across all persistent identifiers.
>
> Thumbwrestling about interpretations of RFC3986 is distracting from 
> the hard problem, IMO.
>

To be clear, I'm not proposing that we define a new URI scheme to serve 
the same purpose as URNs.  (I don't mind if others define a new URI 
scheme for purposes similar to that of URNs or for any other purpose, 
that's just not what I'm proposing.   Though I don't really think that 
creating a new scheme to do what URNs were intended to do will actually 
help much, if any.)

RFC 2141 defines "/" as a reserved character for URNs (just like "?" and 
"#"), so I'm proposing that we define what it means in the context of 
"extended URNs", and that we use it to define "facets". (Whether the "/" 
and what follows is "part of" the URN is something to be determined, but 
this is probably not as important as defining what it means.)

RFC 3986 (erroneously, IMO) tried to shoehorn URNs into a generic URI 
syntax.  Software that tries to treat an "extended URN" as a URI 
according to the RFC 3986 grammar, might get confused by trying to treat 
facets as a "path", for example when processing "relative URIs" and 
perhaps in other cases.    That's not ideal, but I think it's better 
than defining a new URI scheme to do what URNs were intended to do, 
better than not permitting URNs to have facets, and better than defining 
"?" and/or "#" to mean something different for URNs than they mean for 
other URIs.   I strongly suspect that most software that can currently 
accept both URNs and other kinds of URIs, treats the URNs as opaque 
strings.   That software will presumably keep working with faceted 
extended URNs - or perhaps it will be necessary to avoid using extended 
URNs in such contexts until that software is updated.

(It is of course possible that I've missed some more compelling reason 
why "/" cannot be used to introduce facets in extended URNs, in which 
case please accept my apology and point out what I've missed.)

> Isn't this how they were originally defined for URIs?

I don't remember.    Does it matter?

> single URN, let alone across all URN namespaces, how would this work?

Good question.    I can think of cases where a fragment or query would 
be meaningful across all URLs to which a URN resolved (e.g. the URLs are 
replicas of the same resource, or the URLs name each of several versions 
of a resource all of which have the same fragment space and/or interpret 
queries in the same way), and I can think of cases where a fragment or 
query would not be meaningful across all of those URLs.   And this is a 
property of the resource named by the URN, since a URL can be associated 
with multiple URNs (some of which might have the property and some might 
not).   My suggestion would be:

In the absence of a positive indication from the resolution service that 
fragments and/or queries are meaningful (either for all URLs associated 
with that URN, or on a per-URL basis), treat use of a fragment or query 
with that URN as undefined and/or an error.

Keith