Re: URNs for 'naming authority assignment', not 'permanent'

> The "urn" namespace was defined as a system which had no
> defined operational interpretation for determining the
> resource identified; rather, it allowed namespace authorities
> to create naming rules, and that the receiver of a URN
> would have to use other means to actually locate the
> resource.
>

It might be useful if we can make URN to "support multiple operational
interpretations (or de-referencing mechanisms)", instead of having "no
defined operational interpretation". This is different from URL which uses a
fixed de-referencing mechanism, namely the DNS.

It seems that the true power of URN is to allow separation of operational
interpretation from the namespace definition. But this doesn't mean that we
have to exclude the dereference mechanism from the namespace definition.
Instead, we might need a syntax that allows different operational
interpretations to be used for certain namespaces. One way to do this could
be to extend the URN syntax from:

  (1)    "URN":<nid>:<nid-specific-string>

to:

  (2)   <urn-nid>:[ <nid-dereference-mechanism>: ]<nid-specific-string>


Syntax in (2) allows different operational interpretations to be used to
resolve a URN identifier. Here <nid-dereference-mechanism> can be used to
designate each specific de-referencing mechanism. This is different from URL
, where DNS is the only dereference mechanism.

For example, the URL "foo:<foo-name>" has a fixed way to dereference the
<foo-name>, via DNS. The DNS will return the ip-address of the foo-server
that manages the object identified by <foo-name>. The receiver of the
ip-address will communicate with the foo-server via the foo protocol.

Using URN in (2), we may use "foo:hdl:<foo-name>", which will use the Handle
System to dereference the <foo-name>. The Handle System will return service
interface(s) of the foo-server(s) (including their QoS information) that
manages the object identified by the <foo-name>, along with any meta-data
that describes the object. The receiver of these information may select the
most appropriate interface of the foo-server and require its service via the
foo protocol.

Syntax (1) will fit syntax (2) and can be used when no operational
interpretations needs to be specified (or when DDDS serves the default). It
will also allow traditional URLs to be "upgraded" into URN if different
operational interpretations becomes useful...


Well, it seems hurricane Isabel is approaching and we will be shutting down
in a short time. Best wishes to everyone that might be under the
influence...


Best regards,
Sam

Received on Thursday, 18 September 2003 13:51:19 UTC