AppleTalk was a local-area networking protocol stack created by Apple Computer. It was built into every Macintosh, and also for a long time in practically every PostScript printer, whether sold by Apple or anybody else.
No configuration for desktop machines. All network addresses were dynamically assigned, so machines could simply be plugged into the LAN and switched on, and they had full network functionality. Only routers required any actual configuration.
No need to worry about network addresses at all. Network services were accessed, not by their addresses, but by user-assigned names. Names mapped, not just to machine addresses, but also to socket numbers (the equivalent of TCP/IP port numbers). Thus, unlike in TCP/IP where practically every application-level service needs its own well-known port number assignment, in AppleTalk only a few low-level infrastructure services (including of course the name-lookup service itself) needed fixed socket numbers: all application-level services could use dynamically-assigned socket numbers.
No centralized name servers. Each machine kept its own track of the names it had registered.
Names referred to services, not to machines. This meant that a service could be moved from one machine to another, and provided it kept the same name, users didn't even need to be told this had happened. Compare CNAMEs in the DNS, which are a bit of a kludge because you have to keep telling people to use the CNAME, not the actual machine name, otherwise the scheme doesn't work.
Browseability. Instead of having to type in any service names, you could simply query the network for all services of the desired type, and display them in a list to choose from.
This was created for the Apple LaserWriter, which was the first popular PostScript printer, and a key part of the original Desktop Publishing industry that the Macintosh spearheaded. The early LaserWriters were considered too expensive to be connected to just one machine, and since the early Macs didn't have enough grunt to run printer-sharing services while serving desktop users, the logical thing was to build the printer-sharing service into the printer itself.
Unlike that piece of excrement known as 
LPD, PAP implemented a full-duplex connection. This was particularly important with PostScript, because with complicated print jobs it was possible to run into errors with exceeding memory or other printer implementation limits, problems with corrupted fonts etc, so if the communication channel didn't allow you to receive any diagnostics back from the printer, it would be as though your print job had simply disappeared into a black hole.
Another important feature of PAP was out-of-band status queries. This meant that, even while the printer was busy with a print job, it could still respond to status queries from other users' machines, telling them it was busy and with whose job. In this way, all other users trying to print were kept in a "waiting to print" state until the printer was free to service them, instead of simply having their requests abort with a "connection refused" response.
Machine addresses were only 24 bits. Socket numbers were only 8 bits.
Didn't really scale very well beyond the LAN environment.
Some sysadmin types, more used to TCP/IP, claimed that AppleTalk was too "chatty" (used too much network bandwidth maintaining its automatic lookups etc). I think this was questionable: even in the days when 10Mb/s Ethernet was considered fast, I never saw this "chat" amount to more than a few percent of bandwidth. For comparison, Novell NetWare (which was very popular around the same time) required every server to periodically broadcast the list of services it was providing, which AppleTalk never did--only AppleTalk routers were required to do periodic unsolicited broadcasts.
Even though Apple itself has been moving away from AppleTalk for some years now, nevertheless its ease of use set a standard that TCP/IP is still trying to match. The effort to do this is called ZeroConf?, and it is trying add the no-configuration-needed, easy browseability etc as an extra layer on top of standard TCP/IP protocols. I guess the reason they want to do things this way is because building such features into the protocol stack at a lower level would cost too much in performance and scalability (as happened with AppleTalk).
2 pages link to AppleTalk:
