Subject: Re: [urn] suggested text for r-components

From: "Svensson, Lars" <[email-masked]>
Date: Tue, 5 May 2015 12:53:48 +0000

Also below:
 
> Below...
> 
> On 4/30/15 12:42 AM, Keith Moore wrote:
> > On 04/29/2015 09:47 PM, Peter Saint-Andre - &yet wrote:
> >>
> >> Overall I'm still feeling queasy about r-components. It's a large
> >> change to the spec and I feel that it's strongly tied to resolution. I
> >> am wondering whether later on (i.e., when and if someone writes a spec
> >> that updates or obsoletes RFC 2276) we can define r-components as a
> >> convention used in relation to URN resolution. Because r-components
> >> are allowed by q-component syntax, this seems feasible. And because
> >> they represent a significant and untried addition to URNs, this seems
> >> desirable (at least to me).
> >
> > Of course r-components are strongly tied to resolution, since their
> > intended purpose is to affect resolution.  :-)
> >
> > The essential thing to establish now, IMO, is the separation between a
> > query that's passed to a resource and a query that's passed to a
> > resolution service (even if part of the logic of that service is
> > implemented in the client).    If we don't do that now, code will be
> > written that passes everything after the first "?" to the resource as a
> > query, and that will make it much more difficult to implement resolution
> > services later without breaking things.
> >
> 
> I think this:
> 
> > However what might work is to define a syntax for r-components in
> > 2141bis and declare that they're reserved for future use by an IETF
> > standard.   And I think we should go ahead and try to define a standard
> > framework for resolution, but maybe that doesn't have to be a blocking
> > item for 2141bis.
> 
> is the sort of thing I was thinking of when I said leaving a "hook".

Works for me. I feel quite comfortable with Keith's proposal, and I guess the exact definition would be an update to rfc 2483.

Lars