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

From: John C Klensin <[email-masked]>
Date: Fri, 25 Jul 2014 07:34:17 -0400

Hi.  I'm sorry it has taken so long to get this note and the
accompanying one out.  Putting together a careful response,
checking it against specific text in 3986 and other documents,
and going over some of those checks with others has taken around
8 FTE hours during a busy IETF meeting with many interruptions.
I hope it is right (there is an additional disclaimer in the
other note) but, if it isn't, can we try to be as specific as
possible, especially about what documents say and what is
[just?] based on common practices and interpretation.  

I've also worked on the two in parallel: there may be
information in either one that helps inform parts of the other.

--On Thursday, 24 July, 2014 22:05 +0900 "\"Martin J. Dürst\""
<[email-masked]> wrote:

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

See following note.

>> (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.
> 
> Okay, great. Then what's that "separation" about?

Getting away from limitations in 3986-imposed restrictions and
semantics considerably below that level.  I think that is in the
slides.  Really.

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

Independent of the problematic restrictions (see above and the
slides), 3986 contains a lot of "stuff" that has no
applicability to 4121 URNs and that could easily be banned from
expanded URNs without any negative effect.  Take the dot-removal
stuff.  It would be fairly simple to just ban those from URNs as
we expand them; as far as I can tell the very restricted forms
allowed by 2141 ban them now.  After several readings, it is not
clear whether, once one expands because 2141, such a ban would
actually be conformant to 3986.

All the machinery for relative URIs (really relative URLs, IMO).
are another example of something that is unneeded for URNs,
could cause confusion if used, but do not appear to be ban-able
on a per-method basis.

At a different level, the syntax production for <patH> (in
Section 3.3)  appears to use an RHS matching rule and/or an
implicit name-component match to link it to the production for
<hier-part> at the beginning of Section 3. I've seen syntactic
metalanguages that allow things like that, but ABNF isn't one of
them (nor, AFAIK, is there anything in its family that does).
There is no production, or set of productions, that I can find
that links through from <URI> (beginning of Section 3) to
<path>.  How confusing that is depends on experience and
perspective, and it may be worse for people with lots of
experience reading ABNF and metalanguages of the same general
style and easier for people who just mentally shrug and move on.
But it is not correct.

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

And they often take, and treat, it as an ordered sequence.  The
issues arises if one has an unordered sequences of, e.g.,
name-value pairs that one wants to express as or embed in
queries because queries are the only tool that 3986 provides.
Out of curiosity, is "Everyone on the Web..." do it another way
in http UPLs, identify one of those factual errors?

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

Yes, and I've said things that agree with that statement several
times.  On the other hand, 

(i) Section 6.2 discusses a comparison ladder and appears to
say, approximately, "apply as many of these operations, in
order, as you  like, with the understanding that going further
up the latter will cost more processing time but eliminate more
false negatives" (see Section 6.2 for the exact statement).
Noting that several of the rungs on that latter are not
applicable for URNs (but would be harmless if mechanically
applied), I can find nowhere in Section 6 that says "compare any
way you like" or "additional types of comparisons are
encouraged, or even allowed, on a per-method basis" except for
Section 6.2.3, which does not appear to me to be applicable to
URNs.

(ii) It appears to me that the statements, e.g., in Section 3.4,
make the query component atomic as far as 3986-based equivalence
checking is concerned and do not make allowance for per-method
parsing, much less reordering in some method-dependent canonical
way, of that atomic unit in making comparisons.  I could find
nothing in Section 6 that contradicts that and I've now read it
carefully three times in the last 48 hours.   If you can, please
point me to it because I'm sincerely wondering what I missed.
If not, can we pull back a bit from statements like "no basis in
facts"?

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

Here we get into a gray area, at least IMO, because 3986 clearly
allows a method-specific implementation to do whatever it wants
to interpret a query string, including treating its components
any way it likes.  But that is not part of the 3986-level
parsing or comparison procedure, it is something that 3986
allows in the process or accessing or considering the object.
The first sentence of Section 3.4 appears to say that, although
I'm not positive that is what it means.   That takes us back to
a discussion that has been going on, IMO, unproductively, for
more than 20 years.  If one believes that URNs are either bogus
or really no different from http-URLs (and I note that all of
your examples are based on the latter), then, yes, all of this
works out except, maybe, the option Section 6 gives for
determining equality by fetching the resources and comparing
them rather than syntax.  If one believes that URNs are a
different sort of more abstract naming critter, then it becomes
less clear what that first sentence means (if anything).

>> 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.
> 
> There's no need to change. It's already mostly done that way
> where it matters.

And, clearly, one option for the URN WG is to say "mostly, where
it matters, no one pays much attention to what 3986 says in
detail, so we should follow common practice and ignore it".   I
don't find that satisfactory but if the WG, which still had a
charter item to align URNs with 3986, thinks it can do that and
survive Last Call, it would be very efficient.

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

To the best of my knowledge, no one has suggested any such thing
as a "MUST compare differently".  I certainly have not.   I note
that Section 6.2.1 appears to strongly discourage bit-by-bit and
byte-by-byte comparisons and prefer character-by-character ones
but also warns that it, and its position on the bottom rung on
the ladder, guarantee a higher proportion of false negatives
than testing based on more subtle parsings of URIs.

However, if one wanted to think about this a different way (I
think it would drag things out and I don't particularly want to
do the work) the comparison part of the problem could be
addressed by 
(i) Modifying Section 3.4 to explicitly allow particular methods
(or just URNs) to impose requirements that subdivide the query
as long as the "from '?' to '#' or end" rule is not violated and
(ii) adding a 6.2.5 that applied to those method(s) only.

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

That was my intent.

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

See above and the slides.   "This all gets treated as one
string" or "this is processed by the user agent after retrieval
and has to be interpreted according to the media type" (not the
exact words of 3986 which I don't have in front of me but, I
believe, an accurate characterization) are semantic
restrictions... or, if you prefer other words, restrictions that
go beyond a simple specification of syntax.   "Relevant" is, of
course, debatable but depends on these other uses and use cases,
not on whether there are semantic restrictions and statements in
3986.

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

I really don't want to have the discussion that leads off
because it involves opening up old arguments and wounds but,
since you have said similar things several times and challenged
me (and others) to refute it...   The problem in the last
sentence is that there is disagreement about what URNx are and
hence what overall picture they fit into.   At least one of the
listed authors of 3986 is on record as not believing that URNs
are legitimate, that the distinctions some people are trying to
make about them make any sense, and, indeed, that there is
anything one can do with a URN that cannot be done with an HTTP
URL.  URNs that fit into _that_ overall picture could be pretty
easy and totally irrelevant to URNs as seen by those who think
they are different and that the differences are important.

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

Sure.  And I intend to say something like that as I'm going
through the slides in the meeting.  At the same time, we aren't
going to say the first unless we conclude that either URNs are
not legitimate or that they aren't legitimate for some of those
uses, especially library-like ones.  Given the charter, if we
reach  that conclusion, I think we are done.  Relative to the
second, we have been trying to talk with them, but we can't have
much of a conversation if we deny either their experience or the
legitimacy of their needs (see other note).
 
> 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.

See other note, but we have no reason to believe that the
requirements are incompatible.  So far the only evidence of "do
my thing but nothing else" or "my needs exclude those of others"
requirements come from those who say "adhere strictly to the
syntax and semantics or 3986" or "don't extend 3986 beyond 2141".

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

Yes, that was the point.

> What URIs do is to provide a very, very course structure for
> identifiers, so that any kind of identifier need can be
> accomodated.

If one accepted PHB's model of URIs --what I've referred to as
"Scheme:<stuff>" or "Method:<stuff>", that would certainly be
true.   If 3986 specified syntax but not semantics, we could
probably make it work.   Given the syntax and semantics, the
"any kind of identifier need" becomes dubious.   I think I've
provided some evidence that is true.  In contrast, you have
asserted "no basis in facts" and "any kind of identifier need".
I've not being persuaded by your evidence, much of which I
believe to be non-existent; you are not being persuaded by mine,
much of which you seem to believe I have not offered.  I don't
see how me make progress on that basis.

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

Please, e.g., look at Dave Worley's strawman about using escapes
to embed everything in the NSS, thereby staying within the 2141
constraints.

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

See above.

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

See above.   My definition of "allowed" may be a little
different from yours because my sense it that the foundation of
several comments on this list is that changes to, or departure
from, 3986 is not allowed to be discussed.

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

No, they will succeed to the extent that the marketplace accepts
what they are doing and/or the browser vendors accept and
implement what they saying and not more openly developed
consensus standards from other areas.  That is more likely to be
the case if W3C endorses and publishes what they produce with
minor or no modifications and that seems to be on track.   At
that point, the only choices IETF will have is whether to have
forked standards covering things of the same name or to give in
and conform to whatever W3C/WHATWG have produced.  I think the
URN situation is, in that regard, quite similar except that some
of the other bodies involved are much more established and
better-known.

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

While you can look at it that way, statements made by several of
the leaders of that group over the last couple of years suggest
much broader intent and applications as well as a view that the
world resolves around the web and that either nothing else
counts or everything else should get in line.  The recent flap
about deprecating the IANA Charset registry is, IMO, symptomatic
of that pattern.

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

But that "terminology hairsplitting" goes to the scope of what
these various specs apply to.  If you turn it around, we
wouldn't be having this discussion at all had someone gone
through 3986 before publication and substituted "URL" or "URI".
>From a different point of view --I think expressed on this list
in the past-- the difficulties with 3986 are precisely that it
was written for URLs and then extrapolated to URNs by changing a
few words.  I think that is an exaggeration at best, but that
the careful attention to the needs of URNs you cite was largely
limited to the URNs of 2141 and not the allowances it makes for
further extension much less needs that were not well-defined at
the time.

I think your comment above reflects the same problem.  If one
can say "URL" and mean "HTTP[S] URLs in a Web Browser context"
but then claim it really applies to all URIs including URNs we
are, at best, in very bad shape wrt communicating with each
other and probably in worse shape to consider the needs of
communities whose needs are very different from those of the
HTTP-URL-in-browser community.  

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

Sadly, that takes us back to the alternate strategy of simply
ignoring 3986 where it is inconvenient and moving on.  It also
takes us down the path of where I think WAHTWG has gone, which
is "enough systems use this that it, rather than anything that
is written into an IETF Standard, is the norm and nothing else
counts".  From some important perspectives, it is actually a
reasonable position to take, but it makes this WG irrelevant:
there are already established URN practices (whether at XML
scale or not may depend on how one measures) that move beyond
2141 so 2141 doesn't need updating except maybe to memorialize
those changes and what 3986 actually says is irrelevant so the
charter item about reflecting it is too.

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

What do you think it says?  See the comments about the
comparison ladder above.

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

Not as I read 3986.  See above, note particularly the 3986 text
about the balance between false positives and false negatives,
and explain to me where you get "up to who is comparing them to
decide".   Again, if it is the consensus of the community that
3986 provisions are meaningless in practice, we don't need the
"URNs are not" draft, we need some notes (independent of this
WG) to move 3986 to Historic as no longer of
protocol-specification interest.

> Slide 15: "Very long, complex spec": If you think you can do
> it shorter, why don't you give it a try?

For URLs, with their history of accreted features and odd cases,
it probably cannot be.  Whether the provisions to handle them
need to apply to all URIs is another 	question.    And, while I
think one should probably go a bit further, I note that the
"Scheme:<stuff>" theory of generic URIs could be written up in
well under a page of substantive text.  That would then require
different specs for each fundamental URI type (where "type" is
probably a class of schemes), with the current 3986 text
providing a good starting point for web-oriented URLs or perhaps
URLs generally.

> "few actually read it": Unfortunately, that shows from time to
> time on this list.

Indeed.

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

But it does go to length and complexity.   What that group of
slides says is only that, were we to decouple from 3986, we
wouldn't need some of its baggage.  I hoped it was clear that I
didn't consider any of it justification for 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)

Perhaps I am reading too much into the "ladder" statements, but
they seemed fairly clear.  And normative as a sequential set of
options.

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

3986 says, pretty clearly I think, that the path ends with a
"?", "#", or the end of the string.   Queries are all of the
text between "?" and either "#" or the end of the string and
cannot follow fragments, and fragments end with the end of the
string.   So I don't see where else 3986 would allow putting an
additional parameter.

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

I should probably have said "resolver class" or something to
that effect.  Will fix the slide.

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

According to my reading, 3986 allows that reading only at the
lowest rung of the equivalency ladder if it allows it at all.
References and comments about "a lot of software" above.

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

Again, I believe that is possible only if one is going to
interpret 3986 very generously.

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

As appears to be the case with 3986 and 3987, at least based on
Wednesday's plenary and related discussions.

    john

---

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

Hi there,

due to time constraints I'll have to focus on a few specific lines below...

> actually be conformant to 3986.

Does dot-removal play any role outside resolving against a base URI, and 
as part as a totally optional comparison function?

> could cause confusion if used, but do not appear to be ban-able

"Unneeded" is not a reason for a split. "Could cause confusion" is more 
severe, but you really need to be more concrete about it.

Generic URI processing code *does* handle relative resolution in a 
generic way. Is this a problem? And what is the intended way to solve this?

If you say "URNs are not URIs" this implies that (1) you can't put a URN 
where a URI is expected anymore, and (2) you can't use generic URI 
processing code. Is this really really the intent?

> them (nor, AFAIK, is there anything in its family that does).

If you believe that there's a problem in the ABNF, by all means submit 
an erratum. That being said, I don't understand what the problem is but 
maybe you can explain it today in more detail.

> style and easier for people who just mentally shrug and move on.

Why is it not correct?

> in http UPLs, identify one of those factual errors?

I didn't get what you think is a problem here.

> Section 6.2.3, which does not appear to me to be applicable to

"Other scheme-specific normalizations are possible." - 
http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.6.2.3.p.4

Why is that not applicable???

> If not, can we pull back a bit from statements like "no basis in

I agree with Martin. Nothing in Section 6 disallows scheme-specific 
additional re-ordering.

> allows in the process or accessing or considering the object.

It is simply out of scope of the generic syntax and semantics.

> less clear what that first sentence means (if anything).

Again, I have no idea what the concrete problem here is.

> detail, so we should follow common practice and ignore it".   I

Is there something specific in 3986 that you think is "commonly 
ignored"? If yes, what?

> as long as the "from '?' to '#' or end" rule is not violated and

There's nothing that needs to be modified here.

> (ii) adding a 6.2.5 that applied to those method(s) only.

6.2.3 already allows URI-scheme-specific comparisons. I really don't see 
a problem here.

> they are different and that the differences are important.

I happen to agree mostly with that author, but then it's totally unclear 
how this affects the technical argument. Can we please stick to what RFC 
3986 says, as opposed to what some of the authors said somewhere else?

> minor or no modifications and that seems to be on track.   At

The IAB and the IESG met with Philippe Le Hegaret on Monday to discuss 
this, and I have a different recollection.

That being said: pulling the WhatWG issue into this discussion is a 
distraction. The reason Anne van Kesteren and others work on their own 
spec (IMHO) has absolutely nothing to do with URNs.

> about deprecating the IANA Charset registry is, IMO, symptomatic

I agree with what they do is problematic. But can we please focus on 
URNs and RFC 3986?

> HTTP-URL-in-browser community.

Do you have a proposal how to fix this problem?

> What do you think it says?  See the comments about the

I agree with Martin. Please be more specific.

> protocol-specification interest.

Again, Martin is right. Software that is aware of URN-specific rules can 
normalize query strings any way it likes (and is defined for that scheme).

> string.   So I don't see where else 3986 would allow putting an

If it hurts, don't do it.

Best regards, Julian