Subject: Re: [urn] Why bother with f-components (fragments) and/or p-components ?

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

On 4/21/15 3:19 PM, Keith Moore wrote:
> On 04/21/2015 12:32 PM, Leslie Daigle (ThinkingCat) wrote:
>>
>> [Apologies for delayed/lost e-mail -- mail server issues. ]
>>
>> In-line...
>>
>> On 4/17/15 8:05 PM, Keith Moore wrote:
>>> On 04/17/2015 05:27 PM, Leslie Daigle (ThinkingCat) wrote:
>>>> Hi,
>>>>
>>>> Thinking through the r-component idea a bit...   I think your
>>>> argumentation for r-components is pretty compelling, especially as we
>>>> work to make clear why f-components don't fit that particular bill.
>>>> However, I am more than a little concerned about getting too complex
>>>> and bolting stuff on at this point.
>>>>
>>>> I won't argue that DDDS has been used for just about everything
>>>> *except* providing the standard for URN resolution, but in working it
>>>> out we I'm sure you recall we did did actually talk through
>>>> "resolution services" (for ease of reference for anyone who missed it
>>>> -- https://tools.ietf.org/html/rfc2483).
>>>>
>>>> Again, not quite what you are describing now (I read you to be
>>>> thinking more about parameters one would send, not services one would
>>>> request), but perhaps enough to illustrate that there is a whole farm
>>>> of things one might wish to consider if one stops and thinks about
>>>> using URNs in action.
>>>>
>>>> I think pursuing r-components as part of this document would slow this
>>>> one down a fair bit.
>>>>
>>>> Is there a way to leave enough of a hook in the syntax to pursue
>>>> r-component as a separate document?  (BTW...  does "??" actually fly
>>>> with URI syntax, or wouldn't the 2nd "?" be part of the q-component?).
>>>
>>> "Leaving [just] enough of a hook" is exactly what I want to do in this
>>> document.  I think that means:  (a) define the syntax for URNs including
>>> that of r-components, (b) explain the role of r-components in URN
>>> resolution, and (c) set up an IANA registry of r-component names and
>>> values.   Maybe also (d) explain how this is syntax compatible with
>>> 3986.  I think that's about enough for 2141bis.
>>>
>>
>> I think that's considerably more than a hook, it's in danger of being
>> a fishing expedition.
>>
>> I might support (a) and (b), (d) is a requirement, but (c) is a real
>> reach unless or until there's  (electronic) ink on (digital) paper for
>> where to go with this idea, as a general idea, with consensus support.
>>
>> Otherwise -- it's one person's great idea, and if you don't happen to
>> finish writing it down, someone else will come along in a decade and
>> fill it in very differently than anything you might ever have thought
>> of (or that we, collectively, might have agreed to).
>
> It's reasonable to want to look at actual text.   And we've certainly
> seen a lot of examples of people coming along in a decade and filling in
> things very differently than originally conceived, in this space.
>
> Of course it's not the registry which is difficult to set up, it's the
> rules for what can go in the registry.

I agree with Leslie that a registry of r-component name-value pairs is 
way out of scope for now - even establishing the registry. Let some 
future (resolution-specific) document do that, if it's even needed.

Peter

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 May 2015 23:06:30 -0400

> future (resolution-specific) document do that, if it's even needed.
So in other words, it's perfectly okay to have no interoperability for 
the meaning of r-components?

Keith

---

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

> the meaning of r-components?

Just as I am not opposed to motherhood and apple pie, I am also not 
opposed to interoperability. However, we don't know anything about 
r-components. They're a hook. How can we start defining name-value pairs 
for services that are themselves undefined?

Peter

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 May 2015 23:35:00 -0400

On 05/26/2015 11:18 PM, Peter Saint-Andre - &yet wrote:
> r-components. They're a hook. How can we start defining name-value 
> pairs for services that are themselves undefined?

An empty registry is better than no registry at all.   Either that or we 
define the r-component syntax but reserve its actual use for a future 
standards-track document.   Based on past experience, I actually think 
the latter is riskier - i.e. r-components are more likely to be used in 
ways that are undocumented and/or non-interoperable if we require 
standards-track than if we simply have a registry.

Then again, I strongly believe that restricting r-components to 
name-value pairs is also a bad idea.

Keith

---

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

> standards-track than if we simply have a registry.

The way I see it, the URI specification and the HTTP specification don't 
define a registry of name-value pairs for the query component in HTTP. 
Instead, the query component is used in a highly flexible manner and 
each service that offers access via HTTP has its own API for interacting 
with the service. In the world of web services, we don't have 
interoperability across all services, but we don't need to do so as long 
as each service has a well-defined API. I don't quite understand why a 
similar regime would not work for URNs.

> name-value pairs is also a bad idea.

I'm confused. In a message earlier in this thread, you said:

    "Leaving [just] enough of a hook" is exactly what I want to do
    in this document.  I think that means:  (a) define the syntax for
    URNs including that of r-components, (b) explain the role of
    r-components in URN resolution, and (c) set up an IANA registry of
    r-component names and values.   Maybe also (d) explain how this is
    syntax compatible with 3986.  I think that's about enough for
    2141bis.

I thought that by suggesting a registry of names and values, you were 
suggesting that r-components would include name-value pairs.

Peter

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 May 2015 00:49:54 -0400

On 05/26/2015 11:43 PM, Peter Saint-Andre - &yet wrote:
> The way I see it, the URI specification and the HTTP specification 
> don't define a registry of name-value pairs for the query component in 
> HTTP. Instead, the query component is used in a highly flexible manner 
> and each service that offers access via HTTP has its own API for 
> interacting with the service. In the world of web services, we don't 
> have interoperability across all services, but we don't need to do so 
> as long as each service has a well-defined API. I don't quite 
> understand why a similar regime would not work for URNs.

HTTP queries are not like r-components.   An HTTP query is evaluated in 
the context of the specific service named by the URL.   An r-component 
should be a directive that potentially can be interpreted by any 
resolution service, not something that's inherently specific to any 
particular resource or namespace. R-components are similar in this 
respect to header field names in email messages, where the meaning of a 
field-name needs to be consistent across all email.
> suggesting that r-components would include name-value pairs.

Since I wrote that, I've come to believe that people will want to use 
relational expressions in r-components to narrow the result set of a 
search, rather than to set options to specific values. Restricting the 
syntax of r-components to name-value pairs would make this more difficult.

On the other hand, as John and I have been discussing, it doesn't take a 
very complex relational expression to make for a very complex and huge 
URN.   So maybe r-components will have fairly narrow applicability, and 
in those applications where it's useful to specify relational 
expressions to narrow the result set of data to be obtained during URN 
resolution, that will need to be specified outside the URN itself - say 
in a call to a URN resolution library from JavaScript or another language.

Keith