Subject: [mdnsext] Architecture for multi-hop Service Discovery

From: Ran Atkinson <[email-masked]>
Date: Sat, 10 Nov 2012 08:40:03 -0500

Operational experience with Service Discovery based on
the (old) AppleTalk protocols was largely positive.  

Back when I worked in a research lab, that same
AppleTalk Service Discovery scheme worked well,
for various services on a campus-wide scope, 
not limited to services on the local link.

If I understand the history here correctly, part of the
reason Stuart worked on both mDNS and DNS-SD was to
replicate that (missing) capability in IP networks.

So it would be useful and productive if someone
knowledgeable (probably someone at Apple then or now)
could explain the architectural approach that AppleTalk
Service Discovery used.

Once that description is available to folks here, perhaps
we might think about how to replicate that concept and
architectural approach.

I think wheels are great, but I'd really prefer that
we avoid re-inventing the wheel if we can use an existing
design that would suit the current needs.

Thanks,

Ran

---

From: Sebastian Hagedorn <[email-masked]>
Date: Mon, 12 Nov 2012 12:06:09 +0100

> not limited to services on the local link.

I'm not an expert on AppleTalk, because back in the day I was mainly a user 
and only just started working as a network administrator, but I think that 
AppleTalk only worked so well because the world was a different place. In 
our campus network you were able to see and print to every 
AppleTalk-enabled printer! I don't think that anybody would want that these 
days. You need administrative limits on what is visible and what is not. 
Zerconf doesn't have that so far, because it was always intended to be 
link-local, but if it is to be extended to the campus, that's definitely a 
requirement.
-- 
     .:.Sebastian Hagedorn - RZKR, Weyertal 121 (Gebäude 133), Z. 2.02.:.
.:.Universität zu Köln / Cologne University - Tel. +49-221-470-89578.:.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 12 Nov 2012 15:07:52 -0500

Useful place for code spelunking on AppleTalk (and very good documentation
for the code and overall technical design and terminology), is:
http://netatalk.sourceforge.net/

Specifically, look at the stuff related to atalkd (and friends) for actual
AppleTalk daemon and router stuff, including printer access protocol daemon
(papd).

Used this a long time ago, extensively.

Yes, avoiding reinventing the wheel is highly recommended.

Brian

On Sat, Nov 10, 2012 at 8:40 AM, Ran Atkinson <[email-masked]>wrote:

> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>