Re: [URN] Re: Relative URLs and URNs

Martin J. Duerst wrote:
> 
> On Fri, 31 Jan 1997, Daniel LaLiberte wrote:
> 
> >  > Thus spoke Omar Syed:
> >  > > 2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
> >  >
> > Ron Daniel, Jr. writes:
> >  > I think assumption 2 is in error. Clients that know the structure of
> >  > a name in a particular namespace are likely to manipulate it.
> >
> > I agree.  Clients, of course, can do whatever they want (whatever they
> > can get away with) anyway, but they have to be able to interpret the
> > structure of an identifier in order to do as much processing of it on
> > their own as they can.  Forcing clients (if that were possible) to
> > always consult a remote server to process the whole identifier is a
> > sure way to make the system unscalable.
> 
> Forcing to consult a *remote* server is a bad thing. On the other
> hand, if we would require that a client *has to* understand anything
> about the structure of certain URNs, that might also be too much
> of a limitation.

I had always thought that one of the beauties of URNs (aside from
persistence) was that clients didn't have to understand anything
about the structure of the <NSS> portion of the URN.  Is there any
reason why they need to since they are going to be using a resolver
to do the N2L, N2R or N2C mapping.  The only reason I can see is
when a client want to create a new URN from a "relative URN" and a
previous "base URN".  If some rules for doing this are established
which apply to all URN name spaces or better yet, if the client
could consult a resolver to create the new URN, this one reason
could be eliminated.

In general, I think that the less processing the clients are required 
to do on the <NSS> the better.  This allows new URN schemes to be
introduced without having to modify all the clients.

Omar