Subject: Re: [urn] II -- fragments and queries Re: suggested text changes for -12 on p-components, f- and q-components in URN resolution, and relative references

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 26 May 2015 21:30:12 -0600

On 4/28/15 8:59 AM, Leslie Daigle (ThinkingCat) wrote:
>
> I've been chewing on the proposed f-component and q-component text.

Me too. I will chew on it further and try to formulate even clearer text 
based on what Keith has so helpfully proposed.

> I
> think we need to be clear(er) about the overall concept:  how do
> fragments and queries fit with instance-independent naming of resources?
>    I think it was, indeed, progress to focus on their use as applied to
> resolution to content (via URN or URL), but I don't think the concept of
> composing parts is quite captured in the proposed text.

Could you perhaps describe a bit more what you mean by "the concept of 
composing parts"?

> It reads as a
> bunch of complex rules, from which people might (or might not) derive a
> shared concept.

Agreed that the shared concept is key here.

> Example:  If I have a URN for a particular article, that could resolve
> to a URL or a URL for a book with a fragment ID for the article's
> position within the book.   Suppose the f-component on the URN is for a
> particular section of the article.  By the rules outlined below, that
> resolves correctly IFF the resolution process goes for content or gets a
> URL that is undecorated by fragments.

That's not good.

> Leslie.
>
> On 4/23/15 2:02 AM, Keith Moore wrote:

<snip/>

>> (new section.  note: text in brackets/italics about r-components should
>> only be included if r-component proposal is adopted)
>>
>> TBD.A. Use of f- and q-components in URN resolution
>>
>> Since a URN, by design, does not contain either explicitly or implicitly
>> the name or address of a network service which can be used to access the
>> resource named by the URN, an application wishing to access that
>> resource must somehow discover one or more "resolution services" which
>> can, given the URN, either provide the resource content directly, or
>> provide information to the application to enable it to access the
>> resource.
>>
>> Though f- and q-components may appear in a URN, they are not assigned or
>> managed by the URN namespace, but instead evaluated in the context of
>> the named resource.   Specifically, an f-component of a URN refers to a
>> "fragment" of the resource named by the URN, and a q-component of a URN
>> is used to specify a "query" to be evaluated by the resource named by
>> the URN.   This convention ensures consistent use of these components
>> across all URN namespaces, and preserves the ability to reference
>> "fragments" of resources named by URNs that have fragments, and to
>> specify "queries" with resources named by URNs that support queries.
>> In order to preserve this ability, f-components and q-components MUST
>> NOT be transmitted to a URN resolution service except when that service
>> is being requested to provide direct access (or access via proxy) to the
>> resource itself.   For all other requests, the client MUST transmit only
>> the "assigned-part" of a URN /[ along with any r-component//, if
>> specified ]/ to the URN resolution service.
>>
>> A resolution service processing a request for a URN MUST ignore any
>> f-component or q-component of that URN unless the request is to provide
>> direct access (or access via proxy) to the named resource.   If the
>> request is to provide access to the named resource (as opposed to, say,
>> resource locations or resource metadata), the resolution service MUST
>> ignore the f-component of the URN and SHOULD (if possible) process the
>> q-component as if it were a query transmitted to the resource, returning
>> the resource's response to that query.  If the resolution service cannot
>> provide the requested access to the resource, but instead returns
>> resource locations, the f-component and q-component of the request URN
>> MUST be ignored in determining these locations, and MUST NOT be included
>> as fragment and query (respectively) in the returned locations.
>>
>> These rules are intended to impose a layer separation between the URN
>> resolution service and the content, and to discourage the URN resolution
>> service from returning different results depending on the presence of f-
>> and/or q-components in the request.
>>
>> If the resource named by a URN that contains an f- and/or q-component is
>> accessed via an intermediate URI (other than a URN) obtained from a
>> resolution service, and that intermediate URI contains neither a
>> fragment nor a query, the q-component (if present) is appended to the
>> intermediate URI as a query, and the f-component (if present) is
>> appended to the intermediate URI as a fragment (in that order).  The
>> resulting URI is then processed according to RFC 3986.
>>
>> Example: If the URN urn:example:foo?bar#zot appears in a link, the
>> client application might transmit the assigned-part of that URN
>> (urn:example:foo) to a resolution service with a request for resource
>> locations.   The resolution service might then return the intermediate
>> URI http://example.com/whatnot/xyzzy as one of those locations.   The
>> client would then append ?bar#zot to that intermediate URI producing
>> http://example.com/whatnot/xyzzy?bar#zot .   This URI would then be
>> processed per normal RFC 3986 rules.
>>
>> A resolution service MAY return an intermediate URI which contains a
>> fragment and/or a query.   If the intermediate URI contains a fragment
>> or a query, any f- or q-component from the URN is ignored.   (This
>> situation is basically no different than anyone composing a URI from a
>> base URI plus a fragment and/or query without being aware of what
>> fragments and/or queries are valid in the context of the named
>> resource.   Any user or document author may combine URIs with arbitrary
>> queries and/or fragments, but that doesn't mean that the results will do
>> what the user or author intended.)
>>
>> Example: If the URN urn:example:foo?bar#zot appeared in a link, a
>> resolution service might be requested to return locations of the URN
>> urn:example:foo .  If such a service returned an intermediate URI
>> http://example.com/whatnot/xyzzy?abcde , neither the q-component ?bar
>> nor the f-component #zot would be appended to the intermediate URI
>> before processing it.
>>
>> If the content of a resource named by a URN containing an f-component is
>> obtained directly from a resolution service, the f-component SHOULD be
>> treated as a "fragment" and evaluated with respect to that content, just
>> as if the content had been obtained from any other service.

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

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Wed, 27 May 2015 17:51:49 -0400

Hi,

In-line…

On 26 May 2015, at 23:30, Peter Saint-Andre - &yet wrote:

> Me too. I will chew on it further and try to formulate even clearer 
> text based on what Keith has so helpfully proposed.
>
>> I

What happens when your URN has f-components and q-components and it 
resolves to a URL with f-components and q-components was the main issue, 
if memory serves…

Leslie.

> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 27 May 2015 21:05:19 -0600

> resolves to a URL with f-components and q-components was the main issue,

Thanks for the clarification. That is indeed a conundrum.

Peter