Subject: DNS-SD: locally defined service names

From: Paul Guyot <[email-masked]>
Date: Mon, 5 May 2003 17:27:17 +0200

Hello all,

I have a question/comment regarding the service names for DNS-SD.
According to the DNS-SD website http://www.dns-sd.org/ and the NBP 
replacement draft 
(http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt) and the SD 
draft (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt), the 
service name shall be of the form _Foo._[tcp|udp].

where Foo is IANA assigned and the underscore is there to avoid 
collision (that's how the RFC 2782 justifies it)

Nevertheless, the RFC 2782 mentions that the service (Foo) could be 
either a IANA defined service or defined locally.

I wonder (a) what is the rationale of not accepting locally defined 
services and (b) if, considering that we use "_tcp.local." suffix for 
local services anyway, we could extend this to Bar._tcp. for local 
services Bar. Or shall I use _Bar for my local services?

This strictness about IANA registration is contrary to the idea that 
although IANA services have the port assigned to the service 
identifier (Foo), DNS-SD gives the port number in addition to the 
service name (the client does not deduce the port from the service 
name).

Here is a real situation where this could be (well, is) used: I 
happen to be developing a multiagent simulation software that picks a 
free port randomly and publishes its service on that port with 
DNS-SD. This allows me to run several instances on the same machine 
and not care on which port they are.

I don't think I'm abusing of DNS-SD and we could imagine local 
peer-to-peer services that uses DNS-SD in the same way. I will not 
register 10 or 100 ports at IANA to be able to run 10 or 100 agents 
on the same machine, it would be a waste of their time and of port 
numbers (plus they'll probably not give me 10 or 100 ports).

I don't mean that IANA registration should never be done. For 
services that are linked to a single port, it is fine and it lets one 
use _Foo._tcp.domain.com services (still have to see when this really 
interacts with multicast DNS, but it's another story). I was happy, 
even if it took 2 months, to register a service now published with 
DNS-SD. But I am not sure it is really worth it for many 
applications, especially peer-to-peer ones, which should also not be 
manually configured when possible but instead take advantage of 
zero-conf (plus in my very case, this makes the set of agents *very* 
robust since the UDP-Multicast group plays the role of a central 
server).

Paul
-- 
NPDS: http://newton.kallisys.net:8080/
Apache: http://www.kallisys.com/