Stuart Cheshire, July 1997.
This is an archive of selected articles from the Net-Thinkers mailing list, on the subject of NBP/IP. Whether or not Apple is interested in doing anything about it remains to be seen, but I'm hanging it out here for the record, just so I can say "told you so" in about five years time :-)
The Net-Thinkers mailing list is a Macintosh-oriented discussion list where all the participants are already familiar with how NBP (the AppleTalk Name Binding Protocol) works. It has been pointed out to me that many people in the Internet community are not aware of these details, so I've also written a brief explanation of how AppleTalk NBP works.
[Note: (July 1998) Partly as a result of this proposal for NBP/IP, I was offered, and accepted a full-time job at Apple. One of the things you can expect to see in the not too distant future is an implementation of the ideas discussed below.]
Date: Mon, 21 Jul 1997 19:21:33 PDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Stuart Cheshire <cheshire@DSG.Stanford.EDU> Subject: NBPIP >> BTW, this list was supposed to be to post and hash out ideas for >> what should be going on on the Net (and how Apple could be involved). >> I would prefer not to see it used to learn about the Web. Okey dokey. How about this? (Everyone at Apple listening?) Service location on IP *SUCKS*. In the Stanford CS department I pull down the Chooser on my Mac, click on a printer from the list, print on it, walk over and pick up my printout. In the same very building on the very same printers, printing from Unix machines is almost an impossibility. You have to manually enter lots of bizarre information into your /etc/printcap file, and the scope for getting things wrong is vast. Most people have managed to get their machines configured for perhaps one or two of the printers, and then they just live with that. More than once people have come to me to ask me to print files from my Mac for them because they don't know and don't have time to find out and type in all the magic incantations into their Unix machine. Apple has a mature technology for solving this, called NBP (Name Binding Protocol). Apple should just do a straight trivial port of AppleTalk NBP to IP. Tnstead of using AppleTalk and Ethernet multicast it should use UDP and IP Multicast. In place of the AppleTalk addresses would be [IP Address + Protocol + Port Number], but apart from that it should be pretty much identical. There's almost nothing to be done here, certainly no hard design work. Apple just has to define a new NBP packet format for UDP, and define the hash function that maps NBP Types to IP multicast addresses, and publish it. That's it. Once the packet format was published, Apple LaserWriters could listen for and answer NBPIP packets just like they answer AppleTalk NBP packets today, and a new Chooser could send out NBPIP queries in parallel with AppleTalk NBP packets. Once the process was bootstrapped that way, any Internet service could advertise its presence using NBPIP, and people would soon write NBPIP browsers for other platforms. It may be very simple, and not very exciting, but it sure as hell could make people's lives a lot easier. Even if Apple doesn't care about making Unix users lives easier, this matters for Mac users too. As more and more Mac osoftware moves over to using IP, we'd all benefit for a standardized protocol for locating services on IP as easily as the Chooser does on AppleTalk today. Stuart Cheshire <cheshire@cs.stanford.edu> * <A HREF="http://www.stuartcheshire.org/">World Wide Web Page</A> * Stanford Operating Systems and Networking Group Research Assistant * Stanford Residential Computing Associate * Macintosh Programmer
Date: Tue, 22 Jul 1997 07:23:21 PDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Jon Wiederspan<jon@comvista.com> Subject: Re: NBPIP At 7:21 PM -0700 on 7/21/97, Stuart Cheshire wrote: > Okey dokey. How about this? (Everyone at Apple listening?) > > Service location on IP *SUCKS*. Now THAT's more like it. :-) > > In the Stanford CS department I pull down the Chooser on my Mac, > click on a printer from the list, print on it, walk over and pick up > my printout. > > In the same very building on the very same printers, printing from > Unix machines is almost an impossibility. Hey, don't forget the wonderful world of configuring printers for Windows NT and '95! Don't let all of those dialog boxes fool you; it will still take ten times longer (at least) to connect an NT machine to a printer over a network than a Macintosh to any Apple printer. > Apple just has to define a new NBP packet format for UDP, and define > the hash function that maps NBP Types to IP multicast addresses, and > publish it. That's it. Once the packet format was published, Apple > LaserWriters could listen for and answer NBPIP packets just like they > answer AppleTalk NBP packets today, and a new Chooser could send out > NBPIP queries in parallel with AppleTalk NBP packets. Once the process > was bootstrapped that way, any Internet service could advertise its > presence using NBPIP, and people would soon write NBPIP browsers for > other platforms. I think I'm missing something. How would a computer handle the equivalent of "zones" with IP? Right now Macs know the limits of their LANs and resources can exist in different zones which makes it a little easier to find things (although there *has* to be a better way). If the entire Internet is suddenly open to my Chooser will I be seeing thousands of Laserwriters? Will I have to enter the IP address (that also is a bad way to do things, although a nice alternative)? Maybe the Chooser could default to only addresses in the local subnet and then have an option to add other addresses or subnets to scan as well? Jon ================================================================ Jon Wiederspan jon@comvista.com Vice President of Technical Services ComVista, Inc. Author: "Web Sites on the Macintosh" http://www.comvista.com/ http://www.comvista.com/us/jon/wsotm.html
Date: Tue, 22 Jul 1997 10:42:12 PDT To: Stuart Cheshire <cheshire@DSG.Stanford.EDU> From: "J. Ganyard" <ganyard@outer.net> Subject: Re: NBPIP > Apple just has to define a new NBP packet format for UDP, and define > the hash function that maps NBP Types to IP multicast addresses, and > publish it. That's it. Once the packet format was published, Apple > LaserWriters could listen for and answer NBPIP packets just like they > answer AppleTalk NBP packets today, and a new Chooser could send out > NBPIP queries in parallel with AppleTalk NBP packets. Once the process > was bootstrapped that way, any Internet service could advertise its > presence using NBPIP, and people would soon write NBPIP browsers for > other platforms. Aren't we talking about elements of Service Location? As far as I can tell Erik Fair isn't at Apple anymore, does anyone know who (if anyone...) at Apple is tracking the IETF, and is Apple involved in any aspect of SLP?
Date: Tue, 22 Jul 1997 17:58:11 CDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Chris Hanson <cmh@greendragon.com> Subject: Re: NBPIP At 12:42 PM -0500 7/22/97, J. Ganyard wrote: >Aren't we talking about elements of Service Location? As far as I can tell >Erik Fair isn't at Apple anymore, does anyone know who (if anyone...) at >Apple is tracking the IETF, and is Apple involved in any aspect of SLP? I don't know, but SLP was just published as an RFC (#2165), and if I'm not mistaken the people behind it (J. Veizades and E. Guttman) were at Apple originally. Can anybody offer a critique of SLP from the perspective of what we already have in AppleTalk? It looks a little complicated to me.
Date: Wed, 23 Jul 1997 06:42:19 PDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Jon Wiederspan<jon@comvista.com> Subject: Re: NBPIP At 3:58 PM -0700 on 7/22/97, Chris Hanson wrote: > Can anybody offer a critique of SLP from the perspective of what we already > have in AppleTalk? It looks a little complicated to me. It is certainly more complicated than AppleTalk. Doesn't it have to be, though? AppleTalk could count on limited distribution since it is only for internal networks. The scale of the Internet is much too large for that simple of a solution. For the same reason, though, the rewards of implementing a solution like that (and I'm not pushing SLP as the solution) could be great. AppleTalk is still easier to use for filesharing and printing than anything else out there. If the same ease of use (or better) could be brought to sharing IP resources, Apple could slam on the competition a bit (assuming that they actually advertise that it exists). Jon ================================================================ Jon Wiederspan jon@comvista.com Vice President of Technical Services ComVista, Inc. Author: "Web Sites on the Macintosh" http://www.comvista.com/ http://www.comvista.com/us/jon/wsotm.html
Date: Wed, 23 Jul 1997 20:29:44 PDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Stuart Cheshire <cheshire@DSG.Stanford.EDU> Subject: Re: NBPIP Reply-To: Stuart Cheshire <cheshire@cs.stanford.edu> Answers to some comments: >> I think I'm missing something. How would a computer handle the >> equivalent of "zones" with IP? Two possible answers: 1. No Zones. This just works on the local network segment. It solves the problem of "I've got this computer plugged into the same damned office Ethernet hub as my printer -- so why can't I print on it?" 2. Scoped multicast. I know it's not the same as administrative Zone names, but it would be easy to say "show me the printers on the same subnet, within two hops of me, within three hops of me, etc." This would solve the problem of "How do I print on the printer down at the end of the hall?", assuming that a printer within walking distance of your office will usually be within one or two hops of your computer. >> In the case of an IP network it seems that there is no way to get >> around an administrator creating... No no no! No administrators. I'm talking about something very simple that works without human intervention. For huge networks, administrators are necessary. There are definitely big problems to be solved. However, most of the day-to-day problems people face are small problems, but our current IP solutions are only greared towards the big problems. Consequently, even the easy problems (printer and computer on the same Ethernet) end up being as hard for end users to deal with as the problems that *really* are big problems. >> There is already a group at IETF looking into service location protocols >> over IP. Yes, and there have been for about two decades. More on this in a moment. >> I don't know, but SLP was just published as an RFC (#2165), and if I'm >> not mistaken the people behind it (J. Veizades and E. Guttman) were at >> Apple originally. Correct. SLP (Service Location Protocol) supercedes RDP (Resource Discovery Protocol) which supercedes RLP (Resource Location Protocol). RDP was published as RFC 887 in 1983, almost fifteen years ago -- before the first Mac even shipped. There's also RFC 2052 (DNS SRV "A DNS RR for specifying the location of services"). There are plenty of standards. What we need is an implementation. >> Can anybody offer a critique of SLP from the perspective of what we >> already have in AppleTalk? It looks a little complicated to me. It is horribly complicated. You don't just ask it for a list of printers, like in the Chooser. You give it a special query string. To quote the RFC: The Service Request allows the User Agent to specify the Service Type of the service and a Predicate in a specific language. The general form of a Service Request is shown below: <service type>[.<naming authority>]/[<scope>]/[<where>]/ The "scope" is equivalent to an AppleTalk zone, except the RFC says "User Agents make requests of DAs whose scope they are configured to use," which seems to suggest that each client is "configured" by the system administrator to be in one particular "scope". It is not clear whether there is any way for an end user to view a list of scopes, like zones in the Chooser. Notice also that it assumes there's a "DA" (Directory Agent) server running somewhere on the network. The RFC does say "In the absence of a Directory Agent, the request above could be multicast," but the bulk of the document is written assuming that system administrators will be employed to run Directory Agent servers all over your vast enterprise- wide network. Not much for the casual home user here. One example query they give is this: lpr//PAGES PER MINUTE==12, UNRESTRICTED_ACCESS, LOCATION==12th FLOOR/ To me, this is a "big problem" solution. It assumes that there are so many *thousands* of printers in the building that the user couldn't possibly scroll down a complete list to pick one. Instead, they have to formulate a query such as this one to tell the "Directory Agent" which of the printers to list for them. (Also notice the mistake in the example -- a more sensible example would say "PAGES PER MINUTE>=12" so as to also find printers that do 13, 15 and 20 pages per minute, which would also presumably meet the user's requirements adequately.) The "LOCATION" field here is interesting. SLP allows services to register their presence using whatever character set and language they choose. Another example taken from the RFC is that a German printer would register its service using "STANDORT=11 ETAGE". Notice that not only are the words different, but the number is too, because floors are numbered differently in Europe. (Floor n is n floors above ground floor, where as in the US floor n+1 is n floors above the ground floor.) Asking a deeper question, how does the printer even know which floor it is on? It's that ubiquitous system administrator again. All of this relies pretty heavily on having system administrators to configure things. >> It is certainly more complicated than AppleTalk. Doesn't it have to >> be, though? Does it? Perhaps there *is* a need for an extremely complicated labour intensive resource location protocol in very large organization. That doesn't mean there is no need for a simple one. NBP may have its faults, but it's simple, easy to implement, and works wonderfully for connecting to printers and other services on the same network. It would be great for IP to have the same capability. BTW, does anyone know how you choose a file server when you're using AppleShare IP (I don't have a copy). Do you have to type in the name or address of the server you're connecting to? Stuart Cheshire <cheshire@cs.stanford.edu> * <A HREF="http://www.stuartcheshire.org/">World Wide Web Page</A> * Stanford Operating Systems and Networking Group Research Assistant * Stanford Residential Computing Associate * Macintosh Programmer
Date: Thu, 24 Jul 1997 11:50:17 +0800 To: Stuart Cheshire <cheshire@DSG.Stanford.EDU> From: Peter N Lewis <peter@stairways.com.au> Subject: Re: NBPIP Replied: Wed, 23 Jul 1997 21:22:46 -0700 Replied: Peter N Lewis <peter@stairways.com.au> Return-Path: peter@stairways.com.au Return-Path: peter@stairways.com.au In-Reply-To: <199707240329.UAA21316@Pescadero.DSG.Stanford.EDU> Mime-Version: 1.0 >BTW, does anyone know how you choose a file server when you're using >AppleShare IP (I don't have a copy). Do you have to type in the name >or address of the server you're connecting to? Yes. Peter. -- <http://www.stairways.com/> <ftp://ftp.stairways.com/stairways/> <mailto:support@stairways.com.au>
Date: Thu, 24 Jul 1997 07:02:23 PDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Jon Wiederspan<jon@comvista.com> Subject: Re: NBPIP At 8:29 PM -0700 on 7/23/97, Stuart Cheshire wrote: > Answers to some comments: > > >> I think I'm missing something. How would a computer handle the > >> equivalent of "zones" with IP? > > Two possible answers: > > 1. No Zones. This just works on the local network segment. It solves > the problem of "I've got this computer plugged into the same damned > office Ethernet hub as my printer -- so why can't I print on it?" I think this is the only easy, user-drivable option. The "Chooser" would automatically check the local segment. It would also have an interface for locating a resource by IP (as it does now for ASIP) except that it would accept partial strings and do discovery on all IP's in the string. Of course, if the user enters "128." there is a question of whether it is better to tell them they were stupid or just search for a period and return what is found so far. The latter is more consistent with Mac apps. BTW, printers have been the example, but this should be for general resources such as shared volumes, CD towers, and even other services. Why couldn't Mac IP servers like DNS, LDAP and such start advertising their presence to make them easier to find? In that case the "Chooser" could be an interface to InternetConfig for setting IP network preferences. > > 2. Scoped multicast. I know it's not the same as administrative Zone > names, but it would be easy to say "show me the printers on the same > subnet, within two hops of me, within three hops of me, etc." This > would solve the problem of "How do I print on the printer down at the > end of the hall?", assuming that a printer within walking distance of > your office will usually be within one or two hops of your computer. Hops just won't make much sense to the huge majority of users, though. Also, hops may not relate well to physical structures so the "closest printer" in a network sense may not be the closest in terms of a user's ability to reach the printer. > > >> In the case of an IP network it seems that there is no way to get > >> around an administrator creating... > > No no no! No administrators. I'm talking about something very simple > that works without human intervention. I agree that something simple is needed for small networks. But even medium sized networks (OK: small== <250 machines, medium== <Apple-sized network, large== ~Apple or Adobe-sized network, huge== Internet) will need somebody to pre-digest the network information. Hey, zones aren't created by magic. Neither are printer names and access restrictions. These all take an administrator and possibly a print server. Now that's not saying that the administrator's job can't be made incredibly easier by Apple as well. The real problem in that case is the first access to the printer, since it won't have a default IP address, but I doubt that it would kill administrators to use appletalk to reach the printer for the first connection. Once there, a printer can be assigned IP address. While I'm dreaming, how about adding a little more network intelligence to the printers and using those hard disks for something besides fonts? A printer could have Users&Groups built in where access levels could be assigned by username and/or group. Groups can be defined as IP groups as well as user groups (e.g., everyone in 199.238.146.*). Of course, these features are probably better left to a print server since it would drive that sale. The print server could restrict features or complete access (time of day control for access by different groups), prioritize print jobs, manage print queues, track and log print jobs and all of the other usual functions. The print server would also serve as an easy discovery agent server for users. > > [...] but the bulk > of the document is written assuming that system administrators will be > employed to run Directory Agent servers all over your vast enterprise- > wide network. Not much for the casual home user here. I don't think it is wrong to have protocols for large systems and protocols for home users. I don't understand why a home user wouldn't use appletalk and NBP. Even if they have dozens of machines and a couple of printers at their home or small office, I don't see why they would be moving to IP protocols. > > One example query they give is this: > > lpr//PAGES PER MINUTE==12, UNRESTRICTED_ACCESS, LOCATION==12th FLOOR/ > > To me, this is a "big problem" solution. It assumes that there are so > many *thousands* of printers in the building that the user couldn't > possibly scroll down a complete list to pick one. Instead, they have > to formulate a query such as this one to tell the "Directory Agent" > which of the printers to list for them. (Also notice the mistake in the > example -- a more sensible example would say "PAGES PER MINUTE>=12" so > as to also find printers that do 13, 15 and 20 pages per minute, which > would also presumably meet the user's requirements adequately.) The big problem to me is that this is what looks to me like a typical protocol written in the absence of end users. One constant complaint in this list is that Apple doesn't seem to be representing itself well on these committees and groups. There was presumably an opportunity at some point in the process of writing this RFP for someone to mention that there are easier ways already implemented to locate resources and some of those features should be worked into the RFP. Not many companies but Apple have worked to simplify the user experience. Certainly not Microsoft (except when it became obviously profitable and they could buy an implementation) or any of the Unix companies or Novell. > > >> It is certainly more complicated than AppleTalk. Doesn't it have to > >> be, though? > > Does it? Yes, it does. The best design, of course, would be a protocol that degenerates gracefully to a simple local network request (how about multicasting "lpr///"?) but will also support the features administrators need for a large network. > > NBP may have its faults, but it's simple, easy to implement, and works > wonderfully for connecting to printers and other services on the same > network. It would be great for IP to have the same capability. We all agree with that. It's not that I don't like NBP, it's that it won't work over IP so how do we replace it. In case nobody has guessed, I like the idea of two options; one for user-only efforts and one for server-assisted-and-administrator-controlled efforts. > > BTW, does anyone know how you choose a file server when you're using > AppleShare IP (I don't have a copy). Do you have to type in the name > or address of the server you're connecting to? Yes. It is definitely a limited implementation in almost every way. The services are functionally minimal, the AppleShare server itself hasn't gained any of the long-needed features such as time-based access control and it won't even install on machines with less than 32 MB RAM, even though it would run in less if you weren't using all of the features. I've heard good things about future releases (so what else is new) and it works well for small workgroups, but I haven't heard anything about how they plan to update the Chooser and I'm assuming there are no plans to do so. Jon ================================================================ Jon Wiederspan jon@comvista.com Vice President of Technical Services ComVista, Inc. Author: "Web Sites on the Macintosh" http://www.comvista.com/ http://www.comvista.com/us/jon/wsotm.html
Date: Thu, 24 Jul 1997 11:48:43 CDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: fprefect <fprefect@ambrosiasw.com> Subject: Re: NBPIP > We all agree with that. It's not that I don't like NBP, it's that it won't > work over IP so how do we replace it. In case nobody has guessed, I like > the idea of two options; one for user-only efforts and one for > server-assisted-and-administrator-controlled efforts. I responded to an earlier thread on this topic on the MIDAS list a few months ago, and passed along a URL for the implementation I am working on. Its a server-oriented mechanism that could use Internet Config to locate a static well-known service "broker", or even a DNS-extension (similar to MX records) to locate a local broker without pre-configuration on the client side. Anyway, its aimed at short- to medium-lived services, such as games or even file servers on dynamically numbered IPs (over dialup, MacIP). I'm thinking of providing a generic chooser-like application, an HTTP interface, and a code lib that software could link with. <http://www.AmbrosiaSW.com/~fprefect/reggie.txt> Comments are welcome, Matt * * * * * * * * * * * * * * * * * * * * * * * * * * ====================== * Reality: Matt Slot, Bitwise Operator * Time is an illusion. * E-Mail: mailto:fprefect@ambrosiasw.com * Lunchtime doubly so. * Web: http://www.ambrosiasw.com/~fprefect/ * -- Douglas Adams * * * * * * * * * * * * * * * * * * * * * * * * * * ======================
Date: Thu, 24 Jul 1997 11:25:30 CDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Chris Hanson <cmh@greendragon.com> Subject: Re: NBPIP At 10:29 PM -0500 7/23/97, Stuart Cheshire wrote: [Lots of valid criticism of SLP] You might want to send your comments to the working group to see if they can address your concerns. If you like, I could forward them to their mailing list (which I'm following in my copious spare time). >BTW, does anyone know how you choose a file server when you're using >AppleShare IP (I don't have a copy). Do you have to type in the name >or address of the server you're connecting to? Yes. Giant Step Backwards time. At least any alias you make to the server that shows up includes all of the relevant mounting information, so you shouldn't have to do it more than once, but it's bothersome not to be able to browse. (BTW, AppleShare Client 3.7 or 3.7.1 is available via FTP, and includes the ability to mount AppleShare IP volumes. I've successfully mounted a volume over the Internet with it, using the AFP URL mounter thingy from Open Door and a web browser.)
Date: Thu, 24 Jul 1997 10:12:20 PDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Bill Woodcock <woody@zocalo.net> Subject: Re: NBPIP Beware mixing AppleTalk and IP in the way you discuss, lookup in NBP and then switching to IP subsequently. NAT renders this impossible in most real-world environments, once you leave the local segment. -Bill
Date: Thu, 24 Jul 1997 10:47:54 PDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Jim Browne <jbrowne@jbrowne.com> Subject: Re: NBPIP At 07:02 -0700 7/24/97, Jon Wiederspan wrote: >I don't understand why a home user wouldn't use appletalk >and NBP. Even if they have dozens of machines and a couple of printers at >their home or small office, I don't see why they would be moving to IP >protocols. 1) Performance. 2) Cross-platform. (My PCs don't speak AFP, but they FTP just fine.) Jim Browne jbrowne@jbrowne.com "She may be good for nothing, but she's not bad for nothing." - Mae West
Date: Thu, 24 Jul 1997 11:01:12 PDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Jim Browne <jbrowne@jbrowne.com> Subject: Re: NBPIP <delurk> At 20:29 -0700 7/23/97, Stuart Cheshire wrote: >NBP may have its faults, but it's simple, easy to implement, and works >wonderfully for connecting to printers and other services on the same >network. It would be great for IP to have the same capability. Does this list have an archive? If so, there are copies out there of me touting NBP/IP on this list about, oh, two years ago. The reaction from some was "SLP is coming! SLP is coming!". In fact, I'm using Intercon's SLP application right now. *ducks* Stuart, as always, has the right idea. I hope he realizes some success in getting Apple to implement it. </delurk> Jim Browne jbrowne@jbrowne.com "She may be good for nothing, but she's not bad for nothing." - Mae West
Date: Thu, 24 Jul 1997 14:22:47 EDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: "Amanda Walker" <amanda_walker@ascend.com> Subject: Re: NBPIP >In fact, I'm using Intercon's >SLP application right now. *ducks* InterCon never did anything with SLP, and I don't remember us ever promoting it. In fact, I was rather derisive when John Veizades took over the working group, as I remember. InterCon just went ahead and used the "local broadcast" approach. NFS/Share broadcasts to the RPC portmapper port and looks for responses; for every response, it sees if the NFS service is available, and if so, puts the name of that machine into the Chooser list. If anything, this is an existence proof that a simple NBP/IP approach *does* work. Thousands of customers around the world use it every day. Tastes great, less filling :-). Amanda Walker
Date: Thu, 24 Jul 1997 11:57:25 PDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: "J. Ganyard" <ganyard@outer.net> Subject: Re: NBPIP > Does this list have an archive? If so, there are copies out there of me > touting NBP/IP on this list about, oh, two years ago. The reaction from > some was "SLP is coming! SLP is coming!". In fact, I'm using Intercon's > SLP application right now. *ducks* The archive available at http://thumper.vmeng.com/digest/net-thinkers/ Give me day or two and I'll set up a search engine on it... Jeff
Date: Thu, 24 Jul 1997 13:29:22 PDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Jim Browne <jbrowne@jbrowne.com> Subject: Re: NBPIP <delurk> At 14:22 -0400 7/24/97, Amanda Walker wrote: >>In fact, I'm using Intercon's >>SLP application right now. *ducks* > >InterCon never did anything with SLP, and I don't remember us >ever promoting it. > In fact, I was rather derisive when John >Veizades took over the > working group, as I remember. Hi Amanda! Actually, I thought I would poke at Intercon just to see who's still around and listening. With the Ascend buyout, I would think they would force programmers to work on their horribly broken OS for their NAS devices. Adam: Thanks for pulling up that post. Looking back on it (14 months?), I still doubt anyone will implement my solution or Stuart's. </delurk> Jim Browne jbrowne@jbrowne.com "She may be good for nothing, but she's not bad for nothing." - Mae West
Date: Thu, 24 Jul 1997 16:56:41 EDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: "Amanda Walker" <amanda_walker@ascend.com> Subject: Re: NBPIP >Actually, I thought I would poke at Intercon just to see who's still around >and listening. With the Ascend buyout, I would think they would force >programmers to work on their horribly broken OS for their NAS devices. We're still here, doing pretty much what we've always been doing. The InterCon engineering group signed on with Ascend to become Ascend's Client Software Group (we may get a fancier name later, but that's how we're listed in the Ascend phone list at the moment). Our job is to produce software that will make Ascend hardware more attractive to corporate sites. Since the corporate segment is where we were always most successful as InterCon, we're more familiar with it than most of Ascend. And since we're part of core engineering, not a subsidiary, we don't have to try to fund ourselves on just software sales. If a company decides to buy 20 MAXes instead of 20 PortMasters because they get our software bundled with them, everybody's happy :-). So, we're chugging away on a major update of what used to be TCP/Connect (no idea on a new name yet), throwing away much old code and streamlining the UI. You personally may be amused that we've finally dropped the internal NCSA-based IP stack--even Gaige ran out of reasons to keep it now that OT lets you switch interfaces without rebooting :-). It still performs better under some circumstances, but it makes for one less configuration choice. We're stripping out as much configuration UI as possible--lots more configuration by example, many options are migrating to just being peoperties of hotlist entries. We're even in still in the same office space, although Ascend has really spiffed it up with new furniture, equipment, and remodeling. It's nice working for a company that makes money again :-). --Amanda
Date: Thu, 24 Jul 1997 00:49:07 EDT To: "Stuart Cheshire" <cheshire@DSG.Stanford.EDU> From: "Amanda Walker" <amanda_walker@ascend.com> Subject: Re: NBPIP >BTW, does anyone know how you choose a file server when you're using >AppleShare IP (I don't have a copy). Do you have to type in the name >or address of the server you're connecting to? Yup. The IP-aware AppleShare client adds a button under the list in the Chooser, labeled "Server IP Address...". It is quite possibly the lamest UI I have seen for such things in years. I like the "local broadcast" approach. NFS/Share, for example, simply sent a broadcast request to the RPC portmapper, collected the answers, did reverse DNS lookups, and put the resulting names in a list. The result? You pull up the Chooser, clicked on NFS/Share, and saw all of the NFS servers on your subnet. Works great (well, except for certain unnamed defense contractors who were running bridged Class B networks instead of subnetting, but that was clearly not our mistake). So, there's an existence proof that this approach works fine, and even better doesn't violate the Principle of Minimum User Astonishment. --Amanda
Date: Thu, 24 Jul 1997 01:24:29 PDT To: Stuart Cheshire <cheshire@DSG.Stanford.EDU> cc: net-thinkers@thumper.vmeng.com, Leland Wallace <randall@apple.com> From: "J. Ganyard" <ganyard@outer.net> Subject: Re: NBPIP Stuart, Thanks for all of the background and insight to SLP. Am I correct in assuming that you believe that NBP/IP would work more simply and effectively in most LAN environments than an implementation of SLP? > BTW, does anyone know how you choose a file server when you're using > AppleShare IP (I don't have a copy). Do you have to type in the name > or address of the server you're connecting to? There are 2 ways here (currently): 1) in a mixed protocol environment (i.e. Appletalk and IP) a server may be located via NBP in the Chooser - same old AppleShare stuff, if the server is running AS/IP and the client is v3.7 (or someday greater) the server is automatically mounted via IP (for the presumed performance gain - note: this is the default in a mixed protocol environment). There is an implementation of a "fat" alias which may be created which stores both AFP and AFP/IP info for future connections. The user may choose to opt for an AppleTalk only connection by holding down a modifier key (I believe its the option key) when mounting the server. 2) with the new AppleShare client (v3.7) the user is offered a button in the Chooser - "Server IP Address..." for known IP accessible AS/IP servers. Alan Oppenheimer has created a registration app to set the AppleShare client as a browser helper app for AFP URLs called AFP Engage! - check http://www.opendoor.com for more info. He also set up a registration site for anyone running a guest access AS/IP server. See same site. I hope no-one minds, but I forwarded the first message of this thread to Leland Wallace at Apple (on the AppleShare team, primarily working on clients). He defined the syntax of the AFP URL and is working on a similiar project for PAP over IP. I asked him to join the list... Leland, if you are out there, please chime in! Jeff
Date: Fri, 25 Jul 1997 11:50:38 PDT To: Multiple recipients of <net-thinkers@thumper.vmeng.com> From: Stuart Cheshire <cheshire@dsg.stanford.edu> Subject: Re: NBPIP >> Stuart, >> >> Thanks for all of the background and insight to SLP. >> >> Am I correct in assuming that you believe that NBP/IP would work more >> simply and effectively in most LAN environments than an implementation >> of SLP? Precisely. NBP/IP would not be a replacement for SLP. However -- and this is the point -- NBP/IP is simple and trivial to implement. It's about one week's work. In fact there's barely any programming to do. What has to be done is to pick a UDP port, and a range of IP Multicast addresses, and "standardize" and publish them. An alternative strategy for Apple would be to do a full implementation of SLP, and put it in the core OS with published supported APIs. Once that was done, application writers could use the APIs without having to deal with all the grief of SLP themselves. However, that would probably take about a year of engineers time. Moreover, vendors of printers, bridges, hubs, and other specialized hardware would also have to do complete implementations of SLP in order to allow users to automatically locate them on the network. That's why I think something really really simple and easy to implement -- NBP/IP -- would be a big win. >> Alan Oppenheimer has created a registration app to set the AppleShare >> client as a browser helper app for AFP URLs called AFP Engage! - check >> http://www.opendoor.com for more info. He also set up a registration >> site for anyone running a guest access AS/IP server. See same site. AFP URLs are great and really useful, but they're not the answer to out-of-the-box automatic configuration, which is the point of NBP/IP. One of the reasons IP doesn't do automatic pseudo-random address assignment the way AppleTalk does is that if every host picked a random IP address, how would you know what address each host had? Well, if you had NBP/IP, you wouldn't *need* to know what address each host has, and you wouldn't need to type those addresses into your DNS server. You'd just browse the LAN using the Chooser, and it wouldn't matter what address the file server had today. If we had NBP/IP, then Macs on an isolated LAN (not connected to the Internet at large) could just do automatic AppleTalk-style address assignment in the 10.x.x.x range, and use NBP/IP to find each other. This would be good because it would allow us, over the next decade, to gradually retire AppleTalk without having to give up the ease of use that makes AppleTalk ideal for home and small-office LANs. Users wouldn't even have to know that they were using IP. It would just work automatically, the way Macs should. (Please, before I get the flood of flames telling me I'm an idiot, I *do* know what I'm talking about. It *can* work. There's no reason that IP has to use manual configuration and DHCP servers. The 10.x.x.x range is reserved for precisely this kind of use, and on an isolated router-less network you're allowed to use whatever address you choose. The impediment to auto-configuring IP is not anything inherent in IP; it's the lack of a protocol to let you find the hosts once they've auto-configured their addresses.) >> I hope no-one minds, but I forwarded the first message of this thread >> to Leland Wallace at Apple (on the AppleShare team, primarily working >> on clients). He defined the syntax of the AFP URL and is working on a >> similiar project for PAP over IP. I asked him to join the list... Hello Leland. Welcome to the list. Any chance of you delivering this message to someone with a clue in Apple management? Stuart Cheshire <cheshire@cs.stanford.edu> * <A HREF="http://www.stuartcheshire.org/">World Wide Web Page</A> * Stanford Operating Systems and Networking Group Research Assistant * Stanford Residential Computing Associate * Macintosh Programmer