The URN resolution schemes described above all rely to a greater or lesser extent on the Internet Domain Name Service. The dns and x-dns-2 schemes in particular are highly vulnerable to changes in the information registered within the DNS.
Alternative approaches have been proposed which use abstract naming systems such as X.500's User Friendly Names[51] as URNs. SDP could also be used to support an abstract naming system, and hence to provide a URN resolution capability.
Clearly, there could be several alternative approaches to implementing an SDP based abstract naming service, e.g.
In this scenario, the use of SDP would be confined to discovering the nearest server. This would be attractive in so far as it would make it possible for the clients to be configured automatically using a well-known multicast group and port number, and avoid the use of high (global scope) TTLs - provided a sufficiently large number of nameservers are running!
It does not, however, address the issue of communication between nameservers. This could take place using one of the existing techniques, such as whois++ centroid meshes, or perhaps also use SDP...
This scenario would essentially result in a self configuring multicast equivalent to the DNS. A key difference between this and the present DNS based approach to name lookup would be that the strictly hierarchical approach to name assignment could be avoided.
This could greatly reduce the amount of work required in administering Internet namespaces. It would also remove the requirement for namespace administrators to keep - and maintain - lists of domains and nameservers to which they delegate portions of the Internet namespace, or which delgate to them.
Caching would be essential in this scenario, so as to reduce the amount of traffic which required high TTLs.
This scenario would completely eliminate the conventional local nameserver. Instead of being configured to contact a particular nameserver or nameservers for all resolution requests, clients would make SDP requests themselves, process any responses themselves, and issue any quench messages themselves.
There would still be a role for a local nameserver, but this would exist essentially to service local name lookups. Caching would be essential in this approach, to limit the amount of traffic with high TTLs.
This would be attractive in that it would separate out the functions which current nameservers such as BIND perform - name resolution, name service, and caching. This would offer the opportunity to greatly reduce the complexity of the software required to run a nameserver.
The first of these scenarios would be a trivial application of IP multicast, and does not appear to be a particularly demanding application of SDP - this is because there should be no reason to use high TTLs.
By contrast, the latter scenarios would need to excercise all of SDP's features - in particular caching, and behaviour where high TTLs are involved.