Re: URI references and aggregation

Ted,

I'm still struggling to fully understand your position here.  There seem to 
be a couple of points that need to be more fully explored:


At 10:40 AM 1/10/00 -0800, you wrote:
>I think we disagree on the marginal utility of having a single pointer
>type (I don't actually presume that it will always admit of
>resolution, but more on that later).  I believe that there are an
>increasing number of cases (set-top boxes, low-capacity devices, etc.)
>where having a single pointer type will help.  I don't think that
>would affect more capable devices and their ability to use multiple
>pointer types.

It seems to me that a URL (potentially) represents such a wide range of 
possible pointer types that calling it a "single pointer type" is kind-of 
strange.  I find it difficult to appreciate that allowing URNs and URLs 
really adds much in the way of complexity.  At the end of the day, they're 
all URIs.

> > (b) the unregistered feature tag form is defined as using URI syntax, not
> > limited to being a URL.  So a mechanism for resolution is not necessarily
> > always present.
>
>In practice, URIs are currently URLs and URNs.  My presumption is that
>the long-term referencability requirements for URNs make them unlikely
>choices for unregistered feature tags.

[...]

>I'm not convinced that all of the tags can be URNs (the unregistered
>tags seem to fail the permanence test for at least some cases).  I'm
>also not sure what the advantage is of going to a URN form; it's less
>recognized and the resolution mechanisms are less clear.  Certainly
>ad-hoc methods like substituion of URN:namesapce for http://host/path/
>raise the question: why not just start with "http://host/path/" ?

OK, I've misunderstood the nature of a URN.  I was trying to capture the 
idea of an identifier that was not bound to a specific resolution protocol, 
like "mid:..." or "cid:..." [RFC2392].  I had not thought of these as URLs, 
but on closer examination that's just what they are.

I agree that my proposals should not have been so URN-centric.

But I still fail to see any real advantage in excluding the use of URNs.  I 
think they effectively
amount to just another scheme that a limited system may or may not be able 
to handle.



And other minor questions:

> > As far as I can tell, you are proposing what is, in effect, a direct
> > mapping from feature tag to URL:
> >
> >     Tag --> URL
> >
> > and a corresponding:
> >
> >     Aggregate --> URL
>
>Yes and no.  I would retain the syntactic difference between the URL
>pointers to Tags and those pointing to aggregates using both position
>and markers.  I don't propose collapsing them into the same syntax.

I'm not sure what you mean here (particularly by "using both position and 
markers").


> > I trust I've not grasped _completely_ the wrong end of your proposed.
>
>And I hope that my comments at least begin to elucidate the original argument;
>sorry if the first message was less than clear.

I think my mental fog is clearing a little ... sorry to be so dense.

#g


------------
Graham Klyne
([email protected])