<2/4/99 - Manually transferred from Netscape internal bug system, bugsplat. Bugsplat number 148159. I removed the business case information. If you need it, refer to the bugsplat bug.> RFE: Access to a local LDAP server in Off-Line mode The customer is looking for the client to intelligently interpret the server name 'localhost' and allow access to the server while in offline mode. Basically, the customer developed a Disconnected Corporate Directory that replicates against their Netscape DS3.0 LDAP infrastructure. This "Disconnected Corporate Directory" is a local SLAPD (U of Michigan) - Win32 compiled directory server. To use it in Communicator, they set the Ldap server = localhost All seems to work in "Online mode" . But when in "Offline" mode, Communicator complains that it cannot search this directory since you are offline. The is due to the TCP/IP connections not being turned on in offline mode. Customer spoke with Phil Peterson. Phil understands what the customer is looking for. ------- Additional Comments From lalam 06/19/98 17:46 ------- Setting TS1 for this RFE per this business case: Business Case: <see bugsplat bug> ------- Additional Comments From phil 06/20/98 13:46 ------- Fixed for Nova M11. ------- Additional Comments From rburns 07/28/98 14:58 ------- I am unsure how to test this. If anyone has any idea please let me know, I would be more than happy to mark it Verified. ------- Additional Comments From phil 07/28/98 17:23 ------- The verification is pretty involved: 1. Set up an LDAP server on your machine (!) 2. Add that server to your Address Book in Nova, with the hostname "localhost" 3. Use Communicator's "Work Offline..." command to go offline, and unplug from the network. 4. Use Communicator's Address Book to search the directory for stuff. If it works, the bug is fixed. The important new feature is that we still allow LDAP network operations to happen while you're offline, but only against the machine "localhost". As you know, network operations are generally disabled if you're in offline mode, but "localhost" is a special case. ------- Additional Comments From lchiang 08/17/98 13:20 ------- setting up an LDAP server may be involved. Check with tcrowe to see if we can verify this bug on the machine where he has the LDAP server set up. ------- Additional Comments From yoel 12/16/98 13:12 ------- The customer and I have tested this in 4.5, it still does not work ------- Additional Comments From yoel 01/24/99 17:42 ------- Sorry I forgot to reopen the defect when I update it. I tested this and did not get it to work, so did the customer. ------- Additional Comments From hannigan 01/25/99 12:45 ------- We are not adding bugs to 4.0x base - RESOLVED as WONTFIX - and no new features in 4.5x base ------- Additional Comments From yoel 02/02/99 12:17 ------- can we have this considered for 5.0? ------- Additional Comments From raym 02/03/99 09:45 ------- As we do with all RFE's I'm assigning this to 5.0 team and setting the TFV accordingly

qa contact to laurel.

I think I'm on the hook for some LDAP work. Accepting with M9, which is close to "later". I have no idea why this didn't work. I thought we fixed it...

Moving all Mail/News Networking bugs to Mail/News Networking-Mail This may re-open previously Verified bugs due to a Bugzilla bug...if so, I will fix those bugs.

might not do this one...

Does not need to be fixed for PR1

I'll accept this, but it's low priority.

LDAP replication is not going to make Seamonkey. Moving onto the helpwanted list.

Marking M30.

has anything happened on this since then? (bug cleaning)

has anything happened on this since then? (bug cleaning)

This sort of feature would be a good enhancement to Thunderbird mail and news, as well as the SeaMonkey suites mail/news, since the two products share lots of back end code. With several extensions expanding the need for a directory repository, we need "localhost" linking through the TCP/IP stack to empower calendar and protocol handler functionality. There is an evolving vision at MailCo to blend emerging social networking concepts with traditional personal communications.

While having a fix for this would be nice, it seems to me that the number of users likely to take advantage of it is _extremely_ tiny: running a local LDAP server is a pretty heavyweight solution to almost any problem that I can think of. While we'd accept a patch for this, if people are looking to spend effort to help Tb3, this doesn't seem like a very leveraged way to do so.

All that said, this probably really wants a much lower-lever patch to Gecko that would effect all IP traffic. I don't believe there's anything special about LDAP here.

Filter on "Nobody_NScomTLD_20080620"

(In reply to comment #13) > All that said, this probably really wants a much lower-lever patch to Gecko > that would effect all IP traffic. I don't believe there's anything special > about LDAP here. indeed. the core bugs are Bug 87717 - Conn: Offline: localhost/127.0.0.1 not accessible Bug 339814 - Offline mode prevents access to localhost marking dependent on the older bug 87717. but if someone concludes bug 339814 is the better blocker ...