Subject: [urn] r-component syntax

From: Melinda Shore <[email-masked]>
Date: Sun, 10 May 2015 10:50:58 -0800

Hi, all:

There seems to be agreement on specifying a syntax for r-components,
largely as a defensive mechanism against possible future bad behavior.
Rather than specifying that space as "reserved" it probably makes
more sense, and is more consistent with IETF practice, to distinguish
between things that are used as part of URN processing and things that
are opaque to URN processing and passed through without being touched
(thanks to John for providing some clarifying thoughts on this).  Is
there agreement on this?

Thanks,

Melinda

---

From: John C Klensin <[email-masked]>
Date: Sun, 10 May 2015 15:27:58 -0400

--On Sunday, May 10, 2015 10:50 -0800 Melinda Shore
<[email-masked]> wrote:

> There seems to be agreement on specifying a syntax for
> r-components, largely as a defensive mechanism against
> possible future bad behavior. Rather than specifying that
> space as "reserved" it probably makes more sense, and is more
> consistent with IETF practice, to distinguish between things
> that are used as part of URN processing and things that are
> opaque to URN processing and passed through without being
> touched (thanks to John for providing some clarifying thoughts
> on this).  Is there agreement on this?

Melinda, thanks.

As a shortcut to save a bit of time, I think that, if we decide
to allow r-components, the syntax for in section 3 of 2141bis-11
would change so that the changed productions would read:

       q-component = "?" query [ "??" r-component ]
	       Note that <query> in the above cannot contain "??"
       r-component = query

That could also be done in a somewhat more complex way to
eliminate the note, e.g., as 

       q-component = "?" q-string [ "??" r-component ]
       r-component = r-string

where the definition of q-string would repeat the text of
Section 3.4 of RFC 3986 but explicitly exclude, and terminate
on, "??" as well as "#" and r-string would match that Section
3.4 text.

It could also be done more like:

      namestring    = assigned-name
                      [ q-component [r-component] ]
                      [ f-component ]
       q-component = "?" q-string
       r-component = "??" r-string

If anyone who thinks we should adopt r-components has a strong
preference among those alternatives, please say so, otherwise,
Peter and I will draw straws or equivalent.

Independent of the above, if we are going to adopt r-components,
we will need some text to describe them and some examples,
preferably real.  Peter and I can make that up, but suggestions
from WG participants who have thought deeply about this would be
much better.

   best,
    john

---

From: Keith Moore <[email-masked]>
Date: Sun, 10 May 2015 17:37:51 -0400

> on, "??" as well as "#" and r-string would match that Section

I had two reasons for suggesting that r-component precede (appear to the 
left of) q-component:

1.  Doing so places no constrains on the contents of q-components. 
Granted that it's unlikely that there are many existing services that 
use "??" within a query, but it seemed safer to not assume that.

2.  Putting r-components first preserves the property of http[s] and I 
think most other URIs that components are processed left-to-right.   
With most URIs, query processing happens before fragment processing (the 
fragment might apply to the output that the service generates in 
response to the query).     With a URN, the r-component should be used 
first (during resolution), then the q-component (query sent to 
resource), then the f-component (fragment of result).

> from WG participants who have thought deeply about this would be

Let me see what I can come up with.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sun, 10 May 2015 19:38:33 -0400

--On Sunday, May 10, 2015 17:37 -0400 Keith Moore
<[email-masked]> wrote:

>>> touched (thanks to John for providing some clarifying
>>> thoughts on this).  Is there agreement on this?
>> Melinda, thanks.
>> 
>> As a shortcut to save a bit of time, I think that, if we
>> decide to allow r-components, the syntax for in section 3 of
>> 2141bis-11 would change so that the changed productions would
>> read:
>> 
> I had two reasons for suggesting that r-component precede
> (appear to the left of) q-component:

Hmm.  Glad I asked the question.

> 1.  Doing so places no constrains on the contents of
> q-components. Granted that it's unlikely that there are many
> existing services that use "??" within a query, but it seemed
> safer to not assume that.
> 
> 2.  Putting r-components first preserves the property of
> http[s] and I think most other URIs that components are
> processed left-to-right.   With most URIs, query processing
> happens before fragment processing (the fragment might apply
> to the output that the service generates in response to the
> query).     With a URN, the r-component should be used first
> (during resolution), then the q-component (query sent to

With the understanding that I'm mostly agnostic (and, again,
speaking only for myself), the counterargument is that, if
r-component comes first, then it has to be terminated by "?" or
"#" and "?" cannot appear within it.  As an example, chosen
because I'm getting tired of Western European examples and ones
that rely on ISBNs or ISSN, but exposing my bias toward
name-value pairs, assume one was looking for an instance of an
object within, say, India, with the UK as a second choice,
wanted to identify an edition-style, and, if the object was
retrieved, ask about a particular chapter (or some there term),
so we might have

URN-processing info: ?location=IN,GB?Ed=Shakala?lang=hi-IN
Information to be passed to object or its processor:
?verse=X.71.1

Now, leaving the particular work as an exercise, with
r-component second, we would have:

 urn:....?verse=X.71.1??location=IN,GB?Ed=Shakala?lang=hi-IN

(noting that additional material in the q-component could just
use "?" as a delimiter), while r-component first would give us:

 urn:....??location=IN,GB%3FEd=Shakala%3Flang=hi-IN?verse=X.71.1

My rather extreme negative reaction to requiring the use of
%-encoding to achieve the basic structure of a URN (or other URI
string) was what initially sent me in quest of a way to
accomplish and identify both functions without lexical division
of one of the p-/q-/f-components into subcomponent fields and
then led me, instinctively, to r-component second.

I note that the underpinnings of the example above would lend
itself to non-ASCII characters in the NSS and/or p-component, so
%-encoding is likely, adding to the confusion if it is also
necessarily used to encode "?".

It is a tradeoff against your two arguments.  Personally, I find
it pretty persuasive because, (1) forcing r-components into
%-encoding in order to support embedded "?" seems like a far
worse constraint than forcing q-components into %-encoding if it
were necessary to embed "??" (or "#", etc.) and (2) while I
recognize the reality of the "processed from left to right"
convention that you identify, I couldn't quickly find that (as
distinct from "parsed from left to right") as a requirement
except in the context of the 3986 discussion of hierarchical
identifiers (Section 1.2.3) to which URNs are already exceptions
in several respects.

>> Independent of the above, if we are going to adopt
>> r-components, we will need some text to describe them and
>> some examples, preferably real.  Peter and I can make that
>> up, but suggestions from WG participants who have thought
>> deeply about this would be much better.
> 

thanks.

    john

---

From: Keith Moore <[email-masked]>
Date: Sun, 10 May 2015 20:27:23 -0400

>> resource), then the f-component (fragment of result).

FWIW, I just remembered a 3rd reason for putting r-component to the left 
of q-component [*]:

3. Putting r-component to the left of q-component means that the 
portions of the URN that get fed to the resolution service are 
adjacent.    So it's conceivable that the portion of a URN fed to a 
resolution service is obtained by removing the q-component and f-component.

I said "conceivable" since my current thinking is that the application 
client actually has to know something about r-components.  E.g. if the 
content specifies an r-component of "u2r;revision=1.2" the client might 
need to know that it can satisfy a "u2r" request by finding a location 
using "u2l" and requesting the resource from that location.   Also, if 
the service request is not specified in an r-component, the client still 
needs to know what to request from the resolution service.   This 
doesn't make me entirely happy, as it is a less-than-clean separation 
between the resolution service and other client behavior, but it's what 
makes the most sense to me at the moment.

As ugly as %-encoding is, I don't think the requirement to encode '?' 
that appears in r-components is a huge problem, given that (as you point 
out) it's quite likely that non-ASCII characters will appear in 
r-components and they'll also need to be encoded.   Given the wide range 
of characters that require encoding that can reasonably appear in an 
r-component, what's the cost of having to encode 0x3f in addition to the 
rest?   But (for reasons which your example makes quite clear) neither 
would I recommend using '?' (encoded or otherwise) as a separator 
between portions (name-value-pairs or whatever) of an r-component.

I also like the idea of being able to copy a URN q-component to a URL 
query component, and a URN f-component to a URL fragment, without having 
to do any re-encoding (and I'm far from confident that these 
translations will only ever be needed in one direction).   I strongly 
suspect that if different encodings are used for queries vs. 
q-components and fragments vs. f-components that implementations will 
botch those translation steps and/or behave inconsistently from one another.

Regarding name-value pairs: I started out thinking that r-components 
should be name-value pairs.   My current thinking is that they're more 
like expressions in WHERE clauses (and some other portions) of SQL 
SELECT statements.   In other words, I think they're more likely to be 
constraints that are imposed on the result set rather than some named 
attributes.   You could of course still express such things with NVPs, e.g.

urn:example:foo:bar??svc=u2c;where=revision_date.gt.%2220140123%22.and.content_type.eq.%22text/plain%22;order=desc;order_by=revision_date;limit=10

but to me, NVPs don't look as useful in r-components as I originally 
assumed they would be.

(though it strikes me that the above example is so ugly, and things 
could easily get so much worse, that maybe we'd be better off encoding 
the entire r-component in base64)

Keith

[*]  To be clear, I didn't actually arrive at this preference using case 
analysis.   Putting r-component to the left just seemed right to me, 
then I saw what appeared to be several advantages of doing it that 
way.    There might be larger disadvantages that I haven't seen yet.

---

From: John C Klensin <[email-masked]>
Date: Mon, 25 May 2015 14:14:57 -0400

Keith,

I've been delaying responding to this in the hope that someone
else would speak up.  But, with the exception of the two of us,
and Melinda, there has been only silence since her note asking
about agreement on 10 May.

In the hope that it will start a conversation, or at least
elicit some "doesn't matter to me, just decide and move on"
responses from others, a few comments about object order.  I've
trimmed most of the original notes. For those who need to go
back and review, see the messages on 10 May at 
http://www.ietf.org/mail-archive/web/urn/current/maillist.html 

My apologies in advance to anyone who does not want to get far
into parsing theory, etc.

--On Sunday, 10 May, 2015 20:27 -0400 Keith Moore
<[email-masked]> wrote:

> FWIW, I just remembered a 3rd reason for putting r-component
> to the left of q-component [*]:
> 
> 3. Putting r-component to the left of q-component means that
> the portions of the URN that get fed to the resolution service
> are adjacent.    So it's conceivable that the portion of a URN
> fed to a resolution service is obtained by removing the
> q-component and f-component.
> 
> I said "conceivable" since my current thinking is that the
> application client actually has to know something about
> r-components.  E.g. if the content specifies an r-component of
> "u2r;revision=1.2" the client might need to know that it can
> satisfy a "u2r" request by finding a location using "u2l" and
> requesting the resource from that location.   Also, if the
> service request is not specified in an r-component, the client
> still needs to know what to request from the resolution
> service.   This doesn't make me entirely happy, as it is a
> less-than-clean separation between the resolution service and
> other client behavior, but it's what makes the most sense to
> me at the moment.

To a considerable extent, we have gotten into a situation in
which, despite the "semantics separation" (aka "syntax only")
decision, we can't make the decisions that would be most natural
for URNs taken in isolation from [other] URIs.  That is, on
balance, ok, but what is driving it has been a lot of notions
and claims about real and hypothetical generic URI parsers,
including discussions of fragments existing separately from URIs
and having their own semantics whatever anyone else says, the
presence of "/" dragging us into relative references, and so on.
The one effort I know of to determine what is actually out there
and what it does (Sam Ruby's efforts that you and others might
have heard discussed on other lists) has not yielded a very
coherent picture and now, I understand, has been suspended
because the browser folks didn't seem to be very interested.

I think it is safe to say that, when one gets to the edge cases,
there is a lot of different behavior out there.  Whether that is
the result of carelessness or not being able to understand 3986
is obviously not the issue.

Absent Sam's results (and asking and answering questions I'm not
sure he has asked), I think it is far more likely that, 3986
aside, "??" first is going to trigger a syntax error in some
generic parser whose authors haven't imagined such things than
getting into the query having shut off any code that treats "?"
as special.

I don't know if it makes any difference in reality (see below),
but the distinction does affect the metalanguage.  If
r-component is to the right, we have

   <query> = <q-component> [ "??" <r-component> ]
where <q-component> is exactly an RFC 3986 <query> with the
restriction that <query-text> cannot contain a literal
appearance of "??" even though "?" is allowed.  That requires a
two-character look-ahead in the parser, but that should not be a
big deal these days.

By contrast, if it is to the left, we really cannot use the 3986
structure any more because 
    [...] ?? foo ? bar
makes "foo" an r-component and bar a <query> but
    [...] ? ? foo ? bar
make the <query> "? foo ? bar".   If one contemplates
error-prone constructions that could yield weird error messages,
that could be a winner.

However, to return to fundamentals, there are two ways to think
about URI parsing.  In one model, it is all hierarchical: the
generic URI parser separates scheme from everything else, passes
the whole business to a scheme specific parser and it does its
thing.  In the other, which has seemed to be the main focus, a
generic URI parser breaks things into designated bits and passes
those bits off to whatever needs to deal with them, presumably
pre-isolated.  In the latter case, it doesn't really make any
difference how things are organized in the URI string -- in
principle we could tag everything, put pieces in random order,
and then recombine the components after parsing -- as long as
the parsing process is plausible and unambiguous.   In
compiler-speak, the output of a generic parser is a parse tree
and "it is better for these things to come in that order in the
raw string" just are not significant as long as pieces of the
tree are passed off to other processors or other processors can
find their place in the tree.

None of that applies to what is (or ought to be) really
important, which is whether end users can make sense of any of
this.  But we know the answer to that question, with or without
r-components: users don't have much of a clue about the internal
structure of URIs and most of what they think they know is
wrong.  All of the esoteric arguments about the meaning of the
various provisions of 3986 just reinforce that few; I'll start
having hope for end users understanding the details and
implications of URI syntax the day I see a one-sheet
pocket-sized card that summarizes all of the relevant details
and does so accurately.   Whatever we do with a trick syntax
that introduces a delimiter (or delimiter sequence) that makes
more differentiation for URNs than is common for URIs is going
to make that problem worse.

>From that point of view, r-component first is probably going to
be a little more intuitive for some users, and a little less for
some others.  For some members of the first group, the case gets
stronger if they think about <fragments> as something separate
and aside from the URI (taking us back to the other argument).
For the others, this either doesn't make any difference (i.e.,
either it is confusing either way and one better get used to it
or URIs more complex than what 2141 permits are essentially
opaque and only a masochist is going to try to understand what
is going on internally.

> As ugly as %-encoding is, I don't think the requirement to
> encode '?' that appears in r-components is a huge problem,
> given that (as you point out) it's quite likely that non-ASCII
> characters will appear in r-components and they'll also need
> to be encoded.   Given the wide range of characters that
> require encoding that can reasonably appear in an r-component,
> what's the cost of having to encode 0x3f in addition to the
> rest?   But (for reasons which your example makes quite clear)
> neither would I recommend using '?' (encoded or otherwise) as
> a separator between portions (name-value-pairs or whatever) of
> an r-component.

While I don't like "ugly", I'm not nearly as worried about it as
I am about the potential of complete confusion about what the
rules are, especially because I believe that URNs are more
likely to actually be seen and typed by users than the typical
multi-line complex URL.   I had occasion last week to review the
discussions that were a major part of killing IRI work in the
IETF and it involved exactly the same issues we've been going
around on for months as well as more recent ones --
relationships between URIs and fragments; when %-encoding is
required, optional, or prohibited; and so on.   The IRI
experience, IMO, was less about the specifics of those
discussions than that they drove people away until there was
insufficient participation on the broader issues to get the work
done.  I think the desire to not repeat more of that discussion
--and suffer the same fate, which I think is a very real
possibility given participation on the list-- is a very strong
argument to avoid more cases of mandatory %-encoding.

> I also like the idea of being able to copy a URN q-component
> to a URL query component, and a URN f-component to a URL
> fragment, without having to do any re-encoding (and I'm far
> from confident that these translations will only ever be
> needed in one direction).   I strongly suspect that if
> different encodings are used for queries vs. q-components and
> fragments vs. f-components that implementations will botch
> those translation steps and/or behave inconsistently from one
> another.

While I agree with the principle you are suggesting, it is not
clear to me what is has to do with the "where does the
r-component go" discussion unless it is an argument for putting
it after the q-component.

> Regarding name-value pairs: I started out thinking that
> r-components should be name-value pairs.   My current thinking
> is that they're more like expressions in WHERE clauses (and
> some other portions) of SQL SELECT statements.   In other
> words, I think they're more likely to be constraints that are
> imposed on the result set rather than some named attributes.
> You could of course still express such things with NVPs, e.g.
> 
> urn:example:foo:bar??svc=u2c;where=revision_date.gt.%222014012
> 3%22.and.content_type.eq.%22text/plain%22;order=desc;order_by=
> revision_date;limit=10
> 
> but to me, NVPs don't look as useful in r-components as I
> originally assumed they would be.

I think the SQL analogy is pure speculation, that all of the
examples we've seen on the list have been much more amenable to
name-value pairs or other constructions (as is most existing
multiple-term query usage I've seen in URIs) and that mixing the
syntax of URIs (which, as suggested above, almost no end user
understands in detail) with SQL SELECT clauses (which probably
fewer end users actually understand) is a recipe for total
confusion.   In particular, I note that we've seen several real
examples where qualifying clauses are needed to distinguish
between "identify object and return information about it" and
"identify specific metadata and return their values".  And that
lends itself rather better to name-value pairs or something
similar than it does to SQL-like constructions, at least unless
the "target" of the URN is actually a relational database or
part of it.  I also note that SQL-like constructions are not
particularly well adapted to non-relational databases, e.g.,
hierarchical constructions and that we not only have a lot of
those around but some of them are built into URI design.

> (though it strikes me that the above example is so ugly, and
> things could easily get so much worse, that maybe we'd be
> better off encoding the entire r-component in base64)

Sigh.  And make the things totally incomprehensible to anything
resembling a user and, without a computer-based decoder, most
experts.

     john

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 26 May 2015 16:03:59 -0600

On 5/25/15 12:14 PM, John C Klensin wrote:
> the parsing process is plausible and unambiguous.

+1

With that in mind, it seems to me that r-component to the right and 
q-component to the left would introduce less potential for ambiguity and 
thus is slightly preferable.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 26 May 2015 16:06:44 -0600

> Peter and I will draw straws or equivalent.

I prefer the latter - it feels more readable.

> from WG participants who have thought deeply about this would be

Yes, text and examples would be appreciated. (Although any examples are 
quite speculative at this point.)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 27 May 2015 14:41:36 +0000

> > Peter and I will draw straws or equivalent.

I feel a bit confused. Is it really meant that the r-component can only exist as an appendix to a q-component? The position of the square brackets suggest that. I always thought that we could pass instructions to a resolver without having a q-component.

My suggestion would be:

		[q-component]
		[r-component]
		[f-component]

(r-component before q-component works for me, too).

> I prefer the latter - it feels more readable.

Yes, the latter syntax is more readable.

> quite speculative at this point.)

I shall discuss with relevant people at my place.

Best,

Lars

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 May 2015 12:40:20 -0400

Regarding the placement of r-components relative to the other parts of 
the URN:   I still believe, for reasons already stated, that having them 
appear on the left side of the q-component (corresponding to the left 
side of the "query" per 3986 syntax) is better than having them appear 
on the right side of any q- or f-component (corresponding to the right 
side of the "query" per 3986 syntax).   However, as far as I can tell, 
either approach can be implemented in a technically sound and 
interoperable way - I just think having the r-component on the left is 
easier to explain and less likely to be incorrectly implemented.   
Assuming I'm right about that last statement, I'll be happy if we can 
get r-components added to the URN syntax in either fashion.

The lack of responses bothers me more, not so much because there's 
nobody else to weigh in on this particular issue, but because I suspect 
that any change in the URN syntax along these lines needs more 
eyeballs.  In particular, it needs the benefit of review by several 
people with experience in implementing web protocols and/or familiarity 
with existing implementations.   Just as an example, it wouldn't 
surprise me at all if there were running code that parses URNs according 
to 3986 or 2141 but expects "queries" for URIs in general to be 
formatted as if they represented data generated from an HTML form (using 
'&' as a separator between name-value pairs) and which doesn't behave 
well when given URIs with queries not formatted like this.   That might 
argue for a very different way of distinguishing r-components from the 
other parts of the URN.

Maybe we'll get some of those eyeballs in Last Call, but that seems like 
an awkward time to have such a discussion.

Some specific responses about syntax:

On 05/25/2015 02:14 PM, John C Klensin wrote:
> If r-component is to the right, we have
>

I'm not sure what you mean by "we really cannot use the 3986 structure 
any more".    In either case the new 2141bis combined syntax for 
<q-component> and <r-component> has to be compatible with the 3986 
syntax for <query> (or at least I assume this is the goal to try to 
minimize pushback from the "3986 is carved in stone"  camp).   If 
<r-component> is on the left, the r-component appears leftmost in the 
<query> preceded and followed by '?'.   If <r-component> is on the 
right, then it appears on the right side of the <query> preceded by 
'??'. With either approach, if the entire <query> ever gets fed to (say) 
an HTTP-based application, without first stripping out the <r-component> 
and whatever separators, neither the results nor any error message is 
likely to make much sense.

> find their place in the tree.
Agreed, that's a very minor concern.   Though to the extent that 
ordinary users get involved in composing or parsing URNs at all, I do 
think that users are more likely to be able to correctly model the 
behavior of URNs when the components are processed left-to-right, than 
when the components are processed middle, left, then right.

(I have no idea how often will ordinary users end up composing or 
parsing URNs.  But, I originally thought that ordinary users would 
rarely end up reading or writing raw HTML, and I was wrong.)

> to make that problem worse.

As far as I can tell, users build up their own mental models for how 
computer systems work.   They rarely understand how things actually 
work, but the models that they build in their heads do a fair job of 
predicting how the computers will behave for the limited range of cases 
that the users have to deal with on a regular basis.   (Any user whose 
models predict significantly more behavior than the average user's 
models is indistinguishable (by ordinary users) from a wizard.)     So 
from that perspective, it's not important that users actually understand 
how URIs or URNs work; what's important is that they be able to build 
models that accurately predict how they'll work for common use cases.

I'm not sure whether any of that helps answer the question of 
r-components on the left vs. on the right.   But maybe that's not 
actually the most important thing to settle right now.   My assumption 
all along has been that people are going to want to bundle URNs with 
resolution service queries, and that's why we need r-components.   It 
then seems to me that the natural purpose of r-components is to narrow 
the set of results from such a query, so instead of "everything the 
service knows about this URN" the client only sees a subset of that.   
And this seems to me to imply that r-components need to be able to 
contain relational expressions. But if that makes r-components too 
complex, too error-prone, too lengthy, etc. (and I'm starting to lean 
that way) then maybe any need to narrow or otherwise manipulate 
resolution service query results would be better accomplished by 
invoking the resolution service from an actual programming language 
rather than stuffing a query into a URN.    And that might make the role 
of r-components a fairly minor one, such that even name-value pairs 
might be overkill.

> it after the q-component.

Maybe an example will help.

Say there's a desire to submit a query to a resource named by 
urn:example:foo with r-component a=b.   Say also that the user is 
prompted for the query string, and that the client doesn't know what 
query strings are valid for the resource so it has to pass all query 
strings to the resource without verifying them for syntax.

If r-components appear on the left, the client generates 
urn:example:foo??a=b?XXXX where XXXX is a %-encoded version of whatever 
the user typed in.   urn:example:foo is resolved to some URL 
xxx://example.com/bar?XXXX , and the same XXXX that was appended to the 
URN gets transmitted to the resource.

If r-components appear on the right, the client generates 
urn:example:foo?YYYY??a=b where YYYY is a %-encoded version of whatever 
the user typed in, subject to the additional constraint that if the user 
typed in two consecutive '?' characters, at least one of those is also 
percent-encoded so as not to confuse a URN parser.   But once 
urn:example:foo is resolved to some URL, it should result in 
xxx://example.com/bar?XXXX , where XXXX is the query string that the 
user typed in subjected to normal %-encoding rules.    XXXX will 
sometimes be different than YYYY, and it's possible that sending YYYY to 
the resource will produce different behavior than sending XXXX.

Yes, it's an edge case, and maybe a very narrow one.   But having a 
robust protocol requires dealing with edge cases.   And I'm not saying 
that the problem cannot be solved - clearly it can, say, by requiring 
that URN-capable clients first produce XXXX and then encode that to YYYY 
using a distinguished encoding that is strictly reversible.   But I 
suspect it's not likely to be implemented correctly.

(Of course this is just another example of the common problem that 
multiple layers of quoting can be very confusing and result in very 
strange glitches.   We've seen it in text processing, we've seen it when 
trying to embed one kind of email address in another, we've seen it in 
scripting languages, etc.   So it's hardly surprising that it crops up 
here also.   The usual takeaway is to try to avoid designing systems 
that require multiple layers of quoting.)

> confusion.

SQL is just an example of a language for narrowing queries with which I 
thought participants of this discussion might possibly be familiar, and 
I couldn't think of an alternative that might be more familiar.  For 
several reasons, I don't think we'd want to actually embed SQL in 
r-components.   But any other language containing relational expressions 
would be no more familiar to users, no less complex (if it were to be 
effective), and no easier to embed in URNs without confusing encoding.

Basically I think my own examples are convincing me that r-components 
are not an effective way to specify how to narrow search results.

>    In particular, I note that we've seen several real

Can you provide an example or two to illustrate how you think NVPs would 
be effective at this?

Keith

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 May 2015 13:04:39 -0400

--On Wednesday, May 27, 2015 14:41 +0000 "Svensson, Lars"
<[email-masked]> wrote:

>...
>> > decide to allow r-components, the syntax for in section 3
>> > of 2141bis-11 would change so that the changed productions
>> > would read:
>> > 
>...
>> > If anyone who thinks we should adopt r-components has a
>> > strong preference among those alternatives, please say so,
>> > otherwise, Peter and I will draw straws or equivalent.
> 
> I feel a bit confused. Is it really meant that the r-component
> can only exist as an appendix to a q-component? The position
> of the square brackets suggest that. I always thought that we
> could pass instructions to a resolver without having a
> q-component.

You are, of course, correct, proving once again that I should
never be allowed to write ABNF, especially when I'm tired.

> 	r-component = "??" r-string

Yes, that is, IMO, correct.

>...

>> Yes, text and examples would be appreciated. (Although any
>> examples are quite speculative at this point.)
> 

thanks,
   john