Subject: RE: Discovering Named Instances of Abstract Services using DNS

From: "Nicolae, Dan" <[email-masked]>
Date: Thu, 08 Aug 2002 12:35:40 -0400

Stuart,

I read it (fast) and I think the idea of using DNS for discovery in ad-hoc
networks is good. I've argued for that two years ago on the UPnP mailing
list. Back then it was about SSDP vs. mDNS. It is useful for simple devices
in simple networks to talk a single protocol for both name resolution and
service discovery.

About how the document suggests DNS can be used for discovery, at this time
I can only say that it may be a good start for discussion. Holding off the
arguments, I will only mention that the idea of defining labels for services
attributes (e.g. _postscript) I don't think it's going to fly. If we are to
use DNS for service discovery I think we should give up the hope of doing
queries by attributes (other than the service name itself).

Dan

> 
> I'd like to take this opportunity to conduct a little survey.
> 
> <http://files.dns-sd.org/draft-cheshire-dnsext-nias.txt>
> 
> How many people have read the draft and think it is a good idea?
> 
> How many people have read the draft and think it is a bad idea?
> 
> At this stage let's hold off on the arguments why --
> right now I'm just looking for a one-line answer:
> "I've read NIAS and I think it is good," or,
> "I've read NIAS and I think it is bad."
>

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Aug 2002 16:33:32 +0200 (CEST)

> queries by attributes (other than the service name itself).

So what is a "service name"? Is it "printer" or something more specific
like "lpr" or "ipp" (which actually name the the protocol used to communicate
to the service?)

I think this is fundamentally different shades of grey.
You could have
	_printer._tcp.<yourdomain>
and an adjunct protocol for discovering the capabilities of the printer
(including the protocols used to send print jobs).

A slightly different shade of grey is to use
	_slp._udp.<yourdomain>
and use the SLP protocol for discovering the capabilities of the printer
(including the protocols used to send print jobs).
In this case the "printer" specific protocol is replaced by an SLP service
template, which describes the attributes.
The difference between "define a service template per service"
or "define a service capability protocol per service" doesn't seem
significant to me - the hard part is figuring out what the standard and
optional capabilities are for a given service.

A different shade (in the other direction) is to use
	_lpr._tcp.<yourdomain>
and
	_ipp._tcp.<yourdomain>
and use lpr/ipp specific ways to discover the capabilities (but not
the protocol used to send the print jobs since that's implicit in the tag).
If there services which support many different protocols this seems
like more work than the above to shades of grey.

  Erik

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 9 Aug 2002 11:39:00 -0700

> like "lpr" or "ipp" (which actually name the the protocol used to 

I believe the intent is to use the service names IANA uses in their 
list of assigned ports. lpr's service name is printer. ipp's serivce 
name is ipp. So a printer supporting both ipp and lpr would register 
_printer._tcp.<domain>. and _ipp._tcp.<domain>.. Registering as just 
_printer._tcp.<domain>. would not work because there are actually two 
protocols running on two different ports. Part of the information 
returned about a service is the port it is running on. In cases where 
the port is not enough to distinguish between two services on the same 
machine, such as the case of lpr where a print queue is also necessary, 
the TXT record is used to specify the additional information. As noted 
before, such information would be protocol specific. Most protocols do 
not need additional information.

-josh