Subject: [urn] Tomorrow''s "URNs are not URIs" topic

From: John C Klensin <[email-masked]>
Date: Thu, 24 Jul 2014 07:36:12 -0400

Hi.

Apologies for these slides being so late, but in-the-hall
discussions had them changing until late last night and again a
few minutes ago.  We are still outside the 24 hour limit I've
proposed occasionally.

Andy, please post to the materials page at your convenience but
note that I'm circulating them directly to get them into
people's hands.

Please note that, while I've drawn some things together in
different ways, I do not believe there is anything in these
slides that is new and has not been discussed on the URN or IETF
mailing lists in the last six months.    They (and the
presentation) are really just a summary to be sure that we are
making the same assumptions about what is going on (and, if we
are not, to expose that efficiently).

In particular:

(1) If people's concerns about "URNs are not URIs" are about
some perceived symbolism, I think we should rework the draft
with a different name and terminology to reduce that symbolism
as much as possible.   The draft is intended to be a pragmatic
solution to a practical problem, not to make any symbolic points.

(2) Some comments on the list have seemed to imply assumptions
that the separation is about changes that would cause generic
URI parsers to fail in massive ways.  It would allow us to do
that.  However, or actually doing so is unnecessary for any way
that I can imagine, would probably create incompatibility with
URNs allowed by 2141 and in use, and, IMO, would be a stupid
move for those and other reasons.  As a parser specification,
3986 only requires [1] a separation of
   method:path?query#fragment
using the delimiters shown.  I don't think we need to change
that in any way that would  cause such a parser, much less a
parser based on 
   method:<stuff>
to fail.
    
To review an example in advance of the slides, 3986 gives a very
specific interpretation to what people --and many existing URL
applications-- consider a sequence of queries, e.g., 
    ?x abc?y def?g=http://foo.example.com/?

3986 allows the sequence but treats it as a single query string.
AFAICT, the only practical difference is that permuting the
sequence of queries would, under 3986, cause two URIs to compare
not equal (one of many types of false negatives for some URL
situations that 3986 predicts).  Because of some expectations
about URNs (e.g., "persistence" and non-retrieval uses), that
restriction may be worth a change, even if the syntax of the
query-collection does not change a bit.

Anyway, I hope the rest of you are looking forward to a
constructive meeting tomorrow, one that makes significant
progress, as much as I am.

Note that these slides are _not_ "final".  I may not use all of
them and they will probably be edited again to improve clarity
for the proceedings if not before tomorrow.

best,
   john

[1] More or less.  The spec is unintentionally tricky and
actually does not quite "work".  I hope we can avoid getting
dragged into that discussion.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 24 Jul 2014 22:05:49 +0900

Hello John, others,

I'm at work late because of a thunderstorm and a lack of raingear.
As I have said before, I'm not in Toronto and will not be able to attend 
remotely.

But the mail below and the slides still contain stuff, to put it shortly 
but bluntly (sorry), that has no basis in facts, and therefore benefits 
from being corrected.

> solution to a practical problem, not to make any symbolic points.

If there is indeed a practical problem (I have asked for one and tried 
to find one myself, but haven't been successful), then the best solution 
is for the draft to describe the actual problem. Name and terminology 
may be important, but they are secondary.

> that in any way that would  cause such a parser, much less a

Okay, great. Then what's that "separation" about?

> dragged into that discussion.

I don't want to get into complicated discussions. But given the number 
of times that people like Julian and me and others have had to correct 
extremely simple misunderstandings and basic logical errors, I would 
appreciate if you could say in detail what you are talking about here. 
There is a high chance that the spec is actually quite simple and does 
work, and I wouldn't want anybody to miss that.

> 3986 allows the sequence but treats it as a single query string.

Well, yes. That's not because RFC 3986 didn't understand URNs or 
whatever, but because there are virtually no such strings around.
Everybody on the Web writes queries like the above as something like:

?x=abc&y=def&g=http://foo.example.com/

> situations that 3986 predicts).

RFC 3986 does in no way limit anybody's choice in how to do URI 
comparisons. Section 6 (http://tools.ietf.org/html/rfc3986#section-6) 
gives a long (but in no way closed or complete) list of some ways to 
compare URIs and some of the applications for these various comparisons.

For the schemes where queries are mostly used (http: and https:), 
queries are mostly interpreted by software on the server, and I can tell 
you that most decent Web frameworks (starting with Ruby on Rails, which 
I know best) do exactly the same with

?x=abc&y=def&g=http://foo.example.com/
and
?x=abc&g=http://foo.example.com/&y=def

and all the other permutation variants.

> Because of some expectations

There's no need to change. It's already mostly done that way where it 
matters. On the other hand, trying to declare by fiat that every place 
that up to now compared URIs by simple character-by-character comparison 
MUST compare those URIs that start with urn: in a different way will not 
get very far.

> for the proceedings if not before tomorrow.

I hope we get the version of the slides that was used for presentation 
into the proceedings (modulo simple typos). Otherwise, it's not worth 
calling these "proceedings". Of course, you can always produce updated 
versions and send them here or publish them wherever feasible.

Now let's get to the slides:

Slide 3: "Written before 3986 and so not really subject to its semantic 
restrictions": As I have tried to explain before, there are really NO 
relevant semantic restrictions in RFC 3986. If there are any, please 
point them out.

Slide 4: "Effectively imposed retroactive requirements on URNs": This 
isn't true. RFC 3986 didn't impose anything on URNs. It was written 
carefully to make sure that URNs fit into the overall picture.

Slide 4: "3986 Could have said ‘if a ◊ (or “?” or #”) appears, it is
used to indicate a “foo”, with the interpretation of
“foo” being scheme-dependent’
– Did not. Specified what “?” and “#” meant and how
and where they were to be interpreted."
The "where to be interpreted" piece is true for "#". That's mostly 
because existing software (for almost as long as the Web has been 
around) does it that way. So "#" is indeed out of reach of URNs, as well 
as any other scheme. But that's not a retroactive requirement that RFC 
3986 did put on URNs. With respect to "?", "the interpretation being 
scheme dependent" is exactly what RFC 3986 says, just in slightly 
different words.

Slide 7: ",," -> ","

Slide 7: "We have no ability to tell them
– Don’t use URNs
– Don’t use URNs in that particular way
… or expect them to listen if we do."
I think we can't for sure expect them to listen, but we can at least try 
to talk to them.

Slide 7: "They can create their own (“forked”) URN standard for
their communities any time they like.
• If we want to retain control of the overall design/
architecture,, we need to treat each community as
having importance"
It's nice to be able to tell others they are important. But how many 
communities are there? If each community wants something different from 
URNs, what will be left of URNs when we are done? What we need is good 
engineering, collect requirements, find solutions that work across these 
requirements, and so on. "Splitting" before we have a clear, documented 
idea of where we want to go doesn't make sense.

Slide 8: "Verify that 3986-conforming queries and
fragments are sufficient for all needs of present
and future communities.": As you indicated with "Requires predicting the 
future with high confidence", this is essentially impossible.
What URIs do is to provide a very, very course structure for 
identifiers, so that any kind of identifier need can be accomodated. It 
has worked well so far, and it should work well in the future. Of course 
this requires target communities to make a minimum of compromises. If 
somebody comes along and says: I want "#" to mean query and "?" to mean 
fragment, that wouldn't work, about as badly as if somebody comes and 
says: I want "table" to mean "bed" and "bed" to mean "table". (sorry, 
didn't see the "bed" on the next slide coming, this is unrelated)

Slide 9: "And the result looks silly enough": Can you (or somebody) tell 
me what kinds of "silly" stuff you are talking about?

Slide 10: "Avoids dealing with generic URI semantics that many
people don’t realize are there": Well, they are not there. If they are 
there, please show them.

Slide 10: "If needed, allows a discussion of other syntax than that
specified for generic URIs": Discussion is always allowed. If at the end 
of the discussion (or in the middle), somebody says: "what about 
replacing this character with this other one, then we don't have to 
"split", then we can always make a split if we really think we need.

Slide 12: "If WHATWG / W3C succeed in killing 3986": W3C doesn't want to 
till RFC 3986. WHATWG will only succeed to the extent that the IETF 
allows it. The best way to think about that spec is to see it as a 
detailed implementation spec to avoid or reduce browser divergence. It 
contains all the stuff a browser implementer needs to know, but 
virtually nothing else. In that sense, "Assuming that persistent names 
without location properties are a myth (or just dumb)" is slightly 
wrong; they are just not relevant for browsers (simply put, because 
nothing happens when you click on them). And by the way, while the spec 
uses "URL", than in no way excludes URNs. It's just that the spec 
writers decided that the term "URL" was much more widely known than 
"URI", and wide familiarity of Web developers with this term was 
considered more important that terminology hairsplitting.

Slide 13: "Case-sensitive query and fragment compares unless changed for 
all URNs.": Even if you want to change that, you probably can't. As an 
example, there are a lot of URNs used for XML namespaces, and these do 
character by character comparison, to the extent that even
"http://example.org" and "Http://example.org" are different despite RFC 
3986 saying schemes are case-insensitive.

Slide 13: "Query is always part of equality comparison – Fragments 
apparently never": Where did you get that from? I'd guess that all the 
examples in RFC 3986 work that way, but where does the spec *mandate* 
it? I'd guess nowhere.

Slide 13: "Urn:foo:bar?a=b?c=d and Urn:foo:bar?c=d?a=b Never compare 
equal": Wrong, it's up to who is comparing them to decide.

Slide 15: "Very long, complex spec": If you think you can do it shorter, 
why don't you give it a try?
"few actually read it": Unfortunately, that shows from time to time on 
this list.

Slide 15: "Extensive sets of rules irrelevant to URNs (e.g.,
relative URLs, dot-removal)": True but irrelevant, because it doesn't 
require a split.

Slide 15: "Complex equivalence algorithm": Wrong. No fixed algorithm. 
Various options for equivalence/comparison/normalization, because that's 
what happens in practice (with a wide range of choices from XML 
namespaces (see above) to what search engines do for optimization)

Slide 16: "my be resolved" -> "may be resolved"

Slide 16: "If we want the third, not with 3986." ("the third" is "As an 
additional parameter (if we allow it)"): Why not with 3986? I don't 
think there is anything in RFC 3986 that would disallow this.

[I personally think it would be somewhat disingenuous to the purity of 
URNs to include the resolver in the URN, but as far as RFC 3986 goes, 
that would be okay.]

Slide 17: "If we need “?a=c?d=e” and “?d=e?a=c” equivalency": The best 
thing to do here is to write these as "?a=c&d=e" or "?d=e&a=c". Not 
everything, but a lot of software will treat these as equivalent.

Slide 18: "If we need such a small deviation
Why separate from 3986": and what if it turns out that we don't need any 
deviation? Given all the 'reasons' for a deviation/split I have seen so 
far, I think that's the most likely outcome, and would definitely save 
some work and other hassles.

Slide 20: "The IESG could apply “not enough energy to do
work” to the URN topic": If the only way for the URN WG to show energy 
is to prematurely agree on a "split" without actually having done the 
necessary legwork to justify it, that would indeed have to be taken as a 
strong sign of no energy.

Wishing everybody a successful meeting,

Regards,   Martin.