Re: Comments on "Generic URN Syntax"

At 23.55 95-07-09, Daniel LaLiberte wrote:
>This is partly a response to a criticism of the path scheme, and
>maybe more importantly a criticism of the generic URN idea and an
>idea for how to deal with as yet undefined and unknown properties of
>URIs.

The criticism I had was not directed directly at the path scheme, but
but to the syntax the path scheme is using. There might be other
proposals which uses this kind of syntax.

>> From: paf@bunyip.com (Patrik Faltstrom)
>
>> At 20.52 95-07-09, Roy Fielding wrote:
>> >On the other hand, you may want to give a more realistic example, like
>> >
>> >   <URN: path:/edu/bigstate/physics/thesis12>
>> >
>> >as a comparison.
>
>> I do not agree with this. There is a need for recognizing the three
>> different parts of a URN by the syntax because different resolution
>> methods might be used when resolving the service/host part and from
>> what is used when sending the "opaque string" to the service.
>
>First of all, why should a different resolution method depend only
>on the "service/host" part and not on the opaque string part?  Second,
>there should be no requirement that the host part is really a host -
>that would be too location dependent wouldn't it?

Of course. I just didn't know what to call it. Sorry, I didn't have
a better word. In my proposal (I don't want to discuss proposals
here, just syntax) for example, that part is an OID, which is no
host at all. It is just something that together with the name
of the schema gives me enough information about what to do with
the opaque string.

>I believe the
>original idea was that the "host" is a naming authority, and its
>presense, along with the "service" (or scheme), gives you two levels of
>subdivision across all URNs, assuming that is sufficient.  For some
>schemes, the naming authority would be the name of a host; for others,
>not.

I agree.

>> For this reason, I don't think that
>> <URN: path:/edu/bigstate/physics/thesis12>
>> should be a valid URN, because you don't know
>> where the hostname ends and the pathname starts.
>
>There are several ways to consider this, if you really want to fold
>the path scheme into a single generic URN scheme.  First, you could
>consider "path" to be the naming authority and everything after it is
>opaque.  Second, you could consider the whole path up until the last
>component after the last "/" as the naming authority and the last
>component is an opaque string.  The latter is how the path scheme
>defines things.  (If you want a different character in place of the
>last "/", I wouldn't object too much.  I think it's not really
>necessary and it would clash with current practice.)

I think it is necessary to have a difference between the three
parts, and if that can be done within the path-scheme usage,
I think it's better, because I want to look at the different
proposals how they work given a common syntax.

>> I know that there is in the path scheme built in
>> functionality to find this border by querying DNS,
>> but I don't like the fact that the syntax by doing this
>> requires a specific protocol for resolution.
>
>The resolution protocol that we define with the specification of the
>path scheme does as you say, but another resolution protocol could
>be used simultaneously and independently, if people thought that was of
>value.  This other resolution protocol could ignore our protocol
>completely and do things however it wanted.  E.g. the handle protocol
>might be used.

...and if you have a different character, you can use Whois++...

>If we don't have such indictions of the properties of a URI as part
>of the URI, what is the alternative?  How bad would it be to have a
>table of scheme names and an extensible list of properties that might
>be appropriate for each scheme?  IANA could maintain the table of
>scheme names, and another table of standardized properties.  When
>a new property comes along, we go through the table of scheme names
>and add the property where appropriate.

This is the other way of going, but  I rather would like the same
syntax and semantics on the URNs before we start discussing the
different resolution schemes. Otherwise we will have plus/minus
things for the schemes just because of syntax and not functionality.

   paf

Received on Monday, 10 July 1995 09:58:38 UTC