Subject: Re: [urn] Queries in URNs

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 30 May 2013 14:11:31 +0000

>> Now, as to your proposal (3), are you suggesting that we allow query
>> components on URNs? What exactly does it mean for a query to be
>> transmitted to the resource named by the URN? What exactly is the resource
>> in, say, URN:ISBN:0-395-36341-1(RFC 3187) or urn:service:sos.fire (RFC 5031)
>> or urn:cablelabs:packetcable-example:ue:rst-sample (RFC 6289)?
> 
> 
> If any of those URNs resolves to a resource for which query strings have
> meaning (note that this can change over time), the URN with the query string
> appended means whatever it means to access that resource using that query
> string.

Just to make sure I understand it correctly:

Say I create a URN for my mailbox: urn:example:mbox:lars which resolves to [email-masked] . Then urn:example:mbox:lars?subject=Hi%20there&body=Hello%20world would resolve to [email-masked]?subject=Hi%20there&body=Hello%20world (which is OK according to rfc 6068 [1])
 
> Of course, query strings aren't meaningful for all resource types and not
> compatible with all access protocols. 

Very true.

> To ask what a URN with a query string
> appended if the resource or access protocol don't support query strings is a
> bit like asking what an ftp: URL with a query string means.

Or sending a query to an http resource which cannot handle it: It's syntactically OK but semantically useless.

If my above reading of your proposal is what you meant it to be I'd willing to support that. A first stab (using wording by Keith):

[[
x.y Queries

This specification adds no syntactical restriction on queries as parts of URNs other than those specified in RFC 3986. When a query is appended to the URN, the query is transmitted to the resource named by the URN.

The exact semantics of the query part of the URN depends on the type of the resource the URN identifies and is beyond the scope of this specification. It should be noted -- however -- that queries are not meaningful for all resource types and not compatible with all access protocols; the exact meaning of a query can only be determined when those two are known. As an example, urn:isbn:0-123-45678-9?page=12 might be meaningful if urn:isbn:0-123-45678-9 resolves to a web page at http://example.com/isbn/0-123-45678-9 and that http resource is a service that can handle queries (in which case page 12 might be displayed). If -- however -- urn:isbn:0-123-45678-9 identifies a PDF document residing at http://example.com/isbn/0-123-45678-9, the query part ('page=12') MUST be passed on to the PDF document identified by that URI. Similarly, if urn:example:mbox:me identifies the mailbox mailto:[email-masked], urn:example:mbox:me?subject=Hello%world would resolve to mailto:[email-masked]?subject=Hello%20world .

Queries as parts of URNs have has no effect on resolution and are not to be confused with queries sent to (http-based) resolvers in order to control service invocation. Those queries are not part of the URN and are dealt with in RFC 2483 bis. If a URN with a query is passed as an argument to an http-based resolution service, the query part -- including the introductory '?' -- of the URN MUST be percent-escaped according to the rules in RFC 3986.
]]

> Though it does occur to me that perhaps the presence of a query string
> should affect URN resolution in one way: it should perhaps indicate a
> preference to have the URN resolved to an instance of the resource and
> access protocol that are compatible with query strings.

Worth thinking about when we go on to RFC 2483bis.

[1] http://tools.ietf.org/html/rfc6068
> Sent from my iPhone
> 
> On May 29, 2013, at 2:25 PM, Peter Saint-Andre <[email-masked]>
> wrote:
> 
> 
> 
> 	-----BEGIN PGP SIGNED MESSAGE-----
> 	Hash: SHA1
> 
> 	On 5/29/13 11:51 AM, Keith Moore wrote:
> 
> 
> 		On 05/29/2013 01:27 PM, Peter Saint-Andre wrote:
> 
> 
> 			-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> 
> 
> 
> 
> 
> 			On 5/29/13 10:50 AM, Keith Moore wrote:
> 
> 
> 				On 05/23/2013 08:47 AM, Svensson, Lars
> wrote:
> 
> 
> 					All,
> 
> 
> 
> 
> 
> 					I revive this thread about queries in
> URNs again since we
> 
> 
> 					need a resolution on this in order to
> proceed with
> 
> 
> 					standardization in other (bibliographic)
> areas [1].
> 
> 
> 
> 
> 
> 					SHORT VERSION
> 
> 
> 
> 
> 
> 					I propose the following:
> 
> 
> 
> 
> 
> 					1) We do not allow queries in URNs,
> since they only make
> 
> 
> 					sense in the context of URN
> resolution services. 2) We defer
> 
> 
> 					the question of how to handle queries
> in resolution services
> 
> 
> 					to RFC2483bis.
> 
> 
> 
> 
> 
> 					If someone can give me a compelling
> case for the use of
> 
> 
> 					queries in URNs *outside* of URN
> resolution services, I'd be
> 
> 
> 					most happy to discuss that and to
> withdraw my proposal.
> 
> 
> 				3) when a query is appended to the URN, the
> query is
> 
> 
> 				transmitted to the resource named by the
> URN.  It has no effect
> 
> 
> 				on resolution.
> 
> 
> 			Keith, are you agreeing with (1) and (2) and adding
> (3), or
> 
> 
> 			proposing (3) instead of (1) and (2)?
> 
> 
> 
> 
> 
> 		I'm proposing (3) instead of (1) and (2).
> 
> 
> 				It's a really Bad Idea to make URL query syntax
> mean something
> 
> 
> 				different for URNs than it does for URLs.
> 
> 
> 			Personally I think allowing queries in URNs is a bad
> idea, but
> 
> 
> 			that passing a URN as a parameter to a URN
> resolution service
> 
> 
> 			would be fine (where the "URN-string" might be
> contained in the
> 
> 
> 			query component of, say, an HTTP URI whose
> authority component is
> 
> 
> 			the resolution service).
> 
> 
> 
> 
> 
> 		I don't think that it makes sense to have the resolution
> service
> 
> 
> 		interpret the query string at all.   If you do that then you block
> 
> 
> 		the ability of the resolved resource to accept query strings.
> 
> 
> 		Either that or you have to create some registry for query
> 
> 
> 		parameters so that the resolution service can tell which
> parameters
> 
> 
> 		belong to it and which belong to the resource.   That way lies
> 
> 
> 		madness, and it's too late to try to restrict what kinds of
> query
> 
> 
> 		parameters a resource can use.
> 
> 
> 
> 
> 
> 		So the solution: stop trying to overload the query string as a
> way
> 
> 
> 		to communicate preferences to the resolution service.
> 
> 
> 
> 	I have no opinions whatsoever on how best to interact with a
> 	resolution service. If a service provider like resolver.example.com
> 	wants to use https://resolver.example.com?input=stringified-urn
> then
> 	that's fine with me.
> 
> 	Now, as to your proposal (3), are you suggesting that we allow query
> 	components on URNs? What exactly does it mean for a query to be
> 	transmitted to the resource named by the URN? What exactly is the
> 	resource in, say, URN:ISBN:0-395-36341-1 (RFC 3187) or
> 	urn:service:sos.fire (RFC 5031) or
> 	urn:cablelabs:packetcable-example:ue:rst-sample (RFC 6289)?
> Perhaps
> 	it's just my lack of imagination, but I'm having a hard time
> 	visualizing how we would pass a query component to a bound book
> in a
> 	library, to the name of an XML namespace, etc.
> 
> 	Peter
> 
> 	- --
> 	Peter Saint-Andre
> 	https://stpeter.im/
> 
> 
> 	-----BEGIN PGP SIGNATURE-----
> 	Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> 	Comment: GPGTools - http://gpgtools.org
> 	Comment: Using GnuPG with Thunderbird -
> http://www.enigmail.net/
> 
> 	iQIcBAEBAgAGBQJRpkgSAAoJEOoGpJErxa2pZQYQAKF/OFRJ9c1D98K0
> tfdUzdsx
> 	W9yCCEBYXvvORqcYcdv8T+5n/ZZXNix29G/CUKHqP6f9BNW2Kgdam
> WkNMCIbzqT1
> 	QYdf99dYcmkvWo21U5UCbvg0dAvoMGnV83m5bi5DRqOM6oF77tFn
> KttVajUnmH/2
> 	QkPdbGXhoTqZ1ebIUbj1SOGgSJkF3s0XhEXVqEagSW1NRCjOBvlStzCV
> /gHehzCO
> 	hhALwucmrASXvG4ZH8TmlWX1vyWCRul1xuUFhAdWXmXTvqigdq+N
> hvF507V+/CO6
> 	I44NbC319D+wds/5YhFD70aaMEM9BqoTs1+pdYMR3jS7RUX+T8FKes
> S8rt4SkJs5
> 	h8DjMLNtdhn9qEQOixyGENd/lKIbwB+OAxGBziWI/XpGIdCTKYfr9+jp
> 7F2hED6/
> 	jPJyb67fzATK2+GG0TEhmkrMzOYF8dMAawO2AWZXd0VCfEnsHbuIRa
> OOF3S0D/d1
> 	voFls33K0Q0HIR0dMnkdV+H8hlhfivJhzALDEIU5XmgiY+O+aKT0O06olB
> 4NCNgp
> 	GtBOMZFBQ5L4ht6WUTRBhUsMuFPHdbcO8d0/IX3Rdnhj/kRR3PK1+
> MjrBO+V0cn+
> 	YvEpo0uYQVugT3xicjfratZ6V2FlHDc1P8rPygDho5QW7dQiFSSXyDt+BE
> xMQWg6
> 	tdJpLTLb8Y3kjbRZ3Lun
> 	=5W1J
> 	-----END PGP SIGNATURE-----
>

---

From: Michael Mealling <[email-masked]>
Date: Thu, 30 May 2013 10:20:40 -0400

(Yes, I'm eavesdropping…)

That language needs to be much clearer when it uses "part of" and "append to". What is being suggested is that you can include a query string along with a URN that you can then send to the resource but that DOES NOT make that query string part of the URN itself. It is a separate thing. There is no 'query part' to a URN. You can carry around a bag of characters with the URN that you send to the resource, and you can even specify a syntax for how you carry them around together, but the query string is still something that is evaluated by the Resource.

So be very very careful about language such as "part of" or "URN with". URNs stand alone.

-MM

Michael Mealling
Co-Founder
Pipefish.com
+1-678-640-6884	@mmealling
Schedule a meeting:  http://meetme.so/michaelmealling

On May 30, 2013, at 10:11 AM, "Svensson, Lars" <[email-masked]> wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 May 2013 10:29:46 -0400

On 05/30/2013 10:11 AM, Svensson, Lars wrote:
> If my above reading of your proposal is what you meant it to be I'd willing to support that.
Your above reading seems to me to be consistent with what I'm proposing.

> A first stab (using wording by Keith):
>
> [[
> x.y Queries
>

Except that I am not sure that I would say "have no effect on resolution".

But again, even without bringing URNs into the picture, we have the 
issue with HTTP content negotiation that a query string or a fragment 
identifier can mean different things depending on the type of document 
that is negotiated.    Presumably the burden is on whoever runs the HTTP 
server to make sure that query strings and fragment identifiers are 
consistently interpreted in the face of content negotiation.   Should 
the burden similarly be on whoever maintains the URN resolution and 
resource servers for a URN to make sure that query strings and fragment 
identifiers are consistently interpreted in the face of URN 
resolution?   I'm not entirely comfortable with the idea, but I'm not 
sure that I have a better answer.   The alternative - that URN 
resolutions should be made with an awareness of fragment identifiers and 
query strings - seems similarly unappealing.

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 May 2013 22:15:56 -0600

On 5/30/13 8:11 AM, Svensson, Lars wrote:
>>> Now, as to your proposal (3), are you suggesting that we allow
>>> query components on URNs? What exactly does it mean for a query
>>> to be transmitted to the resource named by the URN? What exactly
>>> is the resource in, say, URN:ISBN:0-395-36341-1(RFC 3187) or
>> If any of those URNs resolves to a resource for which query strings
>> have meaning (note that this can change over time), the URN with
>> the query string appended means whatever it means to access that
>> resource using that query string.
> 
> Say I create a URN for my mailbox: urn:example:mbox:lars which
> resolves to [email-masked] . Then
> urn:example:mbox:lars?subject=Hi%20there&body=Hello%20world would
> resolve to [email-masked]?subject=Hi%20there&body=Hello%20world
> (which is OK according to rfc 6068 [1])

I'm confused by this example. Why do we have a URN for your mailbox when
mailto:[email-masked] is already a perfectly acceptable URI? And can
we even claim that it's possible to have a persistent,
location-independent identifier for something as transient as a
particular person's email inbox at a particular email service provider?

>> Of course, query strings aren't meaningful for all resource types
>> and not compatible with all access protocols.
> 
> Very true.
> 
>> To ask what a URN with a query string appended if the resource or
>> access protocol don't support query strings is a bit like asking
>> what an ftp: URL with a query string means.
> 
> Or sending a query to an http resource which cannot handle it: It's
> syntactically OK but semantically useless.
> 
> If my above reading of your proposal is what you meant it to be I'd
> willing to support that. A first stab (using wording by Keith):
> 
> [[ x.y Queries
> 
> This specification adds no syntactical restriction on queries as
> parts of URNs other than those specified in RFC 3986. When a query is
> appended to the URN, the query is transmitted to the resource named
> by the URN.

I agree with Michael that we need to be very, very careful about what we
mean here.

As stated, personally I would prefer not to make query components part
of URNs, or to append query components to URNs themselves. If you want
to pass a query component to a resolution service (e.g., via an HTTP URI
for the resolution service), that's something quite different and it
seems fine to me.

> The exact semantics of the query part of the URN depends on the type
> of the resource the URN identifies and is beyond the scope of this
> specification. It should be noted -- however -- that queries are not
> meaningful for all resource types and not compatible with all access
> protocols; the exact meaning of a query can only be determined when
> those two are known. As an example, urn:isbn:0-123-45678-9?page=12
> might be meaningful if urn:isbn:0-123-45678-9 resolves to a web page
> at http://example.com/isbn/0-123-45678-9 and that http resource is a
> service that can handle queries (in which case page 12 might be
> displayed). If -- however -- urn:isbn:0-123-45678-9 identifies a PDF
> document residing at http://example.com/isbn/0-123-45678-9, the query
> part ('page=12') MUST be passed on to the PDF document identified by
> that URI. Similarly, if urn:example:mbox:me identifies the mailbox
> mailto:[email-masked], urn:example:mbox:me?subject=Hello%world would
> resolve to mailto:[email-masked]?subject=Hello%20world .
> 
> Queries as parts of URNs have has no effect on resolution and are not
> to be confused with queries sent to (http-based) resolvers in order
> to control service invocation. Those queries are not part of the URN
> and are dealt with in RFC 2483 bis. If a URN with a query is passed
> as an argument to an http-based resolution service, the query part --
> including the introductory '?' -- of the URN MUST be percent-escaped
> according to the rules in RFC 3986. ]]

I am still confused and indeed mystified as to why the URNs need to have
query components, as opposed to URIs at which URNs are resolved. Am I
just dense, or has this not been explained very clearly by the proponents?

>> Though it does occur to me that perhaps the presence of a query
>> string should affect URN resolution in one way: it should perhaps
>> indicate a preference to have the URN resolved to an instance of
>> the resource and access protocol that are compatible with query
>> strings.
> 

I fully agree, but I would put it this way: query components are worth
thinking about in relation to resolution, but not in relation to the
core definition of URNs.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/