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

From: "Nicolae, Dan" <[email-masked]>
Date: Fri, 09 Aug 2002 12:03:26 -0400

I am about to leave for vacation so I only have time for a few fast
thoughts:

> 
> 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.

I agree. That's exactly why I said that we can only start talking about that
at this time; we must decide where to stop. That would depend on the
zeroconf requirements for service discovery; which I don't think provide
that level of detail yet.

If zeroconf is nothing more than a migration of AppleTalk and NetBIOS
(including the MS Browser), than "printer" is enough.

If zeroconf needs to take into account the IETF-documented printing
protocols, then "ipp"/"lpr" is enough.

If zeroconf does not imply losing any capabilities available in managed
networks (i.e. what SLP can do) then we need SLP.

From what I've heard so far, my impression is that zeroconf means more than
the possibility to function when there is no centralized configuration.
Besides that, it seems that we're also looking for a suite of protocols that
can be easily implemented by simple devices.

>
> 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.
>

Yes, all these are possible. 

It seems like nobody here wants to start from the scratch with the user
requirements. Everybody has one protocol in mind that they've used, they
liked it and now think we should simply mimic it. In UPnP's case, when I
proposed to use mDNS instead of SSDP, it wasn't because DNS is appropriate
for service discovery in general. It was only because the UPnP service
discovery requirements could have been easily achieved with DNS (already
required for name resolution).

So what are the zeroconf requirements for service discovery? Nothing more
than AppleTalk/MS Browser, a lot more (like SLP/LDAP) or somewhere in
between? Once we know that it will be easy to decide if DNS is appropriate
or not.

>   Erik

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 19 Aug 2002 18:42:08 -0700

Erik Nordmark asked:

>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?)

My philosophy here is very deliberately a behavioural model of networking
-- I believe the only sensible question in this context is not, "What are 
you?", but, "What protocol do you speak?"

If you walk like a duck and quack like a duck, then I'll treat you as a 
duck.

If I'm writing an IPP client, then I want to find other things on the 
network that speak IPP. It doesn't matter if they archive the documents 
onto CDR instead of printing them on paper -- if they speak IPP, then my 
IPP client will talk to them.

Conversely, finding "a thing that prints on paper" (whatever that means, 
in a precise sense) and then asking what protocols it speaks doesn't help 
me, if the answer is that it speaks only PSPAPATUDPIP 
(Postscript-over-Printer-Access-protocol-over-AppleTalk-tunneled-over-UDP-o
ver-IP). That's no use at all to a client that implements only IPP.

What an IPP client wants to know is, "Who can I talk to?"

>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).

Right, but you mean, "_printer._tcp.<yourdomain>"
The IANA protocol name for LPR is "printer", not "lpr".
(Search for "515" in <http://www.iana.org/assignments/port-numbers>.)
I made this same mistake in my draft a year ago, and I need to fix it.

A client that implements LPR looks for "_printer._tcp.<yourdomain>"
A client that implements IPP looks for "_ipp._tcp.<yourdomain>"
A client that implements both looks for both.

>like more work than the above to shades of grey.

If there are devices that support many different protocols, then
that itself is the problem, not the discovery step of the process.

If there are n printing protocols, then Apple (and any other client 
vendor) has to support n different ways of printing, each with their own 
features, bugs, and deficiencies. Printer vendors each have to support n 
different ways of printing. That is the big burden.

I'd like to see a world where there's one and only one accepted way of 
printing over IP, and that way of printing works really well.

In the meantime, there are currently a small number of different ways of 
printing, and we do have to support that, but lets recognise that as a 
problem to be reduced over time, not a desirable thing to be proliferated.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org