Good choices, all. Airwolf got me interested in helicopters; before that I thought they were just ungainly oversized bugs. But hey, a flying machine that can go supersonic and still turn on a dime, armed with cool missiles and armor - that's slick. Especially since most of the technology they showed was actually feasible to mount into a helicopter. (KnightRider, on the other hand, was always just something to smirk at...)
Hm, I gotta get hold of the Space 1999 DVDs, it's been ages since I've seen Barbara Bain...
Not only do trademarks have to be registered in a specific field, but they have to be registered in a specific class of product or service. Still, the guiding principle is whether use of the mark will cause confusion for the public.
When I registered my trademark for my band (Highland Sun, http://www.highlandsun.com/ I received a letter from someone who was registering a mark for "Highland Sun Farms" - a horse ranch somewhere (in Kentucky IIRC) asking me to stop using the name as it infringed on his. Even though our two uses of the mark (including graphical design/logo) are completely unrelated, his trademark attorney advised him to contact me. (For a variety of reasons, my claim to the mark had sufficient merit, so I am still using it to this day.) Much as I hate anything associated with IP law, I recognize that that guy was just doing his job, protecting the value of his client's mark.
Having just read through about a half of the debian trademark debate, I'm glad I don't have to wrestle with it. And I give props to the guys who are standing on their principles. I can see valid points on multiple sides of the debate.
1) The guiding principle of Free Software is to give users the freedom to use and distribute the software, without unreasonable restrictions. There are a few restrictions of course, like - you must not claim the software as your own if you didn't actually write it - you must attribute it to the actual authors. In other words, you are prohibited from being a jerk about it.
2) The basic premise of trademarks is that there is value in a name, and that value and name must be protected. As such, use of a trademarked name is tightly controlled, pretty much by definition. (If you're not going to worry about controlling use of the name, then there's no point in getting the trademark registration in the first place.)
I believe if you carry the principles of the Free Software Foundation to their ultimate conclusion (reductio ad absurdum, in this case) then they are incompatible with all three forms of Intellectual Property - copyrights, patents, and trademarks. Because in order to use a piece of software, you need a handle with which to refer to it. Even if I give you the code for free, if I don't let you call it by the same name that other people call it, then your use of the software is severely hampered. e.g. "I just wrote this C compiler. I call it the GNU C compiler. You're welcome to use it too, but you can't use the same name, because I'm afraid you'll make modifications to it that harm its quality, and I don't want your version to harm the reputation of my original code. So you're not allowed to use the words "GNU", "C" or "compiler" in any combination in reference to your copy of it."
Fortunately, nobody needs to carry it to that extreme, because the FSF's goal isn't just Freedom for the sake of some abstract philosophical condition, the goal is FAIRNESS. That's why reasonable restrictions are part of the GPL and other FAIR licenses. "You may distribute modifications of this code, but you must clearly mark your modifications. You must use a different version number. etc..." That's fair - it avoids people confusing your copy for the original, but it allows you to keep referring to it by essentially the same name, so that when people see "gcc-4.0.5-hyc" they have some idea that "oh, this is a customized version of gcc" and they don't have to ask themselves, "wtf is this buffalo-chip-code-generator doing on my distro and why should I care?"
You're missing the point. Even sorting messages into subfolders (there are about a dozen subfolders in that archived Inbox, I collapsed the view so they're not in the screenshot) only postpones the inevitable.
Is it so totally beyond your comprehension that someone may legitimately receive 16,000+ messages all of a particular topic (e.g., a mailing list) that they'd want to save in one place? That is the point of a mail archive, after all.
The fact that this example is the Inbox is irrelevant. It could have just has easily been my archive of the gnu-gcc mailing list or anything else.
If you're routinely putting tens of thousands of items into PST files, you're going to hit a wall, sooner or later, and it has nothing to do with filesystem/disk space.
Yeah, I used to use Outlook 2000. I switched to Mozilla after my Outlook archive.pst died, it hit 16384 items and wouldn't accept any more. So much for archiving... The Mozilla calendar is definitely in sad shape. The Mozilla POP3 client was too, but I bludgeoned the code until it did what I want. Don't have time to do the same for calendar, unfortunately.
The research had probably been going on long before Carly arrived. The biggest connection you could draw between the two is, she didn't axe it during her reign...
In OpenLDAP 2.3 (which has been in beta for a few months and is due for a public release in a few days) the full configuration is editable via LDAP, so you no longer need to restart the server to tweak ACLs, add schema, or reconfigure indexing. In fact you can generate a complete server configuration via LDAP - you can add new backends and start them up and shut them down on the fly.
re: decent GUI tools - yes, this is a problem, but you have to frame it correctly - it is a problem with LDAP software in general. You shouldn't *need* a custom console to configure the service, you should be able to do everything through the basic protocol, regardless of how you access the protocol - command line, standalone GUI, or web application. Most site admins will always need a combination of these tools - command line tools for automated/batched, bulk access and for trivial incidental operations, a GUI to aid in visualizing an overview of the data, and a variety of customized web forms for the day-to-day trivia like resetting users' passwords. A custom console may be helpful, but the ones I've seen so far are overkill for day to day administration, and not flexible enough for real problem resolution. It will be nice to work toward a generic console that can address all of these needs, but I think we'll be stuck writing one-offs for some time yet.
I would never advocate replacing LDAP with DAP, that wouldn't solve anything anyway. My point is that LDAP is only a client to server access protocol, but people thought they could use it for everything and forget about the problems that DSP and DISP were designed to solve. People are trying to do distribution now with LDAP, and beating their heads against the walls.
As a simple example - in X.500, two servers (A and B) that trust each other can establish a DSP session between themselves. If an authenticated client request comes in to server A but data is needed from server B to satisfy the request, the server A can securely chain the request on behalf of the client without any fuss.
In LDAP, if the same situation arises, a couple of things can happen:
server A can return a referral to the client. The referral mechanism doesn't address how to handle security in a referral though. Possibly the two servers support a disjoint set of authentication mechanisms. Possibly one server requires TLS and the other doesn't; that information isn't encoded in the referal. Possibly the referred server is behind a firewall that the client can't cross. There are any number of problems here that will prevent the client from successfully concluding the request. In the absence of any policy information (and where does that come from?) the client may have no choice but to chase the referral using a plaintext Simple Bind. The referral might point to a rogue server, which will then take the client's credentials and feed that info to who knows where.
There's another possibility, for a server that implements chaining via LDAP: in this case you might be able to create the same kind of trusted inter-server session that DSP allows. But since LDAP doesn't have server-to-server support built in, that session needs to be established by means of Controls and Extended Requests. One of the big problems here is that the LDAP standard cannot distinguish between client-server and server-server communication. Any client could legitimately use the same Controls that are intended to facilitate server-server communication; when server A receives a request decorated in this manner, there's no clear way for the server to determine how to progress the request. For example, the Proxy Authorization control, which essentially allows one to say "I'm identity A but please perform this operation with the privileges of identity B." This capability is a key requirement for secure server to server chaining, but if a client issues a request with Proxy Authorization attached, the correct behavior for the server is ambiguous.
Personally I think you just like showing off that you knew LDAP was descended from OSI DAP, and didn't mean to get caught up in this conversation.
Actually, I distinctly remember waking up this morning and thinking to myself "ah, what a nice day. I hope I can get into an argument about LDAP with someone on slashdot, that would be just perfect." Must've been the full moon last night.
Thanks for an interesting read. My impression of Novell eDirectory mostly agrees with yours. A couple of points, not to detract from your excellent post:
OpenLDAP 2.2 back-hdb supports subtree renames. The lack of this feature has been an obvious, longstanding deficiency but that was corrected over a year ago.
Replication strategy - I think this may be an irreconcilable religious issue. I don't believe a feature that allows unresolvable update conflicts is suitable for use, others are willing to live with it because the possibility for problems to arise is usually low.
Actually, I am a founder of Symas Corp. And I made no effort to hide that fact, you can see my associations all over my personal web site (which is linked on all of my slashdot posts) as well as the relevant Symas and other web sites.
Your comparison to Microsoft's "Get The Facts" campaign is way off base. The real point of my posting here is that you are passing anecdotes about things nobody can meaningfully assess or prove on their own.
The information I refer to on the Symas benchmarking page is provable by anybody. The OpenLDAP code can be downloaded by anybody. Anybody can download DirectoryMark and set up the same tests. We documented the hardware we used so that you can have meaningful points of reference for every data point.
Whether you think Symas has a product that's relevant to you is not my concern. I don't care a whit if you buy anything from us or not, and none of my posts said "buy our stuff!"
Been there, done that. At least 5 years ago the first time, and many times since then. Perhaps if you had asked for help you would not have had such a hard time with it. That *is* one of the benefits of working in an open source community after all.
Your reading skills are weak, then. That page refers to the May 2000 study merely to provide a point of reference. The results on that page are all only a couple of months old.
I've already proved you wrong once, haven't you had enough yet?
"Referrals work." Only in a fantasy world where security and authentication are unimportant, and where firewalls don't exist.
The fact that there are still people submitting drafts to the LDAPEXT Working Group to define controls and extensions for real distributed operation is proof that the rest of the world is not as happy as you are with LDAP's server to server capabilities today. If you can't see that, it's no burden to me.
That's OK for you to say, because you've already considered the factors that are important to your individual use case. But LDAP is intended to fit a multitude of use cases and for the protocol designers to take this stand is grossly irresponsible.
You blithely say that "Techniques for bridging between databases" are well understood, but you don't notice that they only work when the entire system and all connections work well. When any component fails or misbehaves, the behavior of the entire system goes into a randomizer. The fact is that in any complex network, the probability is 100% that some component will be failing or misbehaving for a non-trivial amount of the system's operational life. Without paying careful attention to these details, the design will collapse in the face of those outages.
The fact that the LDAP working groups are still struggling with these distribution issues today is a testament to my point - the original LDAP guys didn't do their homework, and now that LDAP has crept in all around the network, the rest of the world is paying the price.
Yet another mindless raving rated as "Insightful" - where do you guys get this stuff?
The above post is a stream of empty claims and not even a hint of factual support. How can you rate someone saying "I haven't looked at the code yet.. it is high quality from its core to its exterior" as *Insightful* ?? There is ZERO insight here.
Nobody here knows what kind of server the Netscape guys were talking about, what those 200,000 clients were doing, or what the directory data looked like. We have No Insight into what that claim means.
But you can look here http://www.symas.com/benchmark.shtml and see charts derived from documented benchmark procedures that You Yourself can repeat and verify, showing that Netscape's performance drops off FASTER than OpenLDAP's as the number of clients increases. You want INSIGHT - doing systematic tests and publishing the tests so that others can verify the results is how you get it. Not by factless gushing from a fanboy who has never seen the code in question.
The LDAP protocol is described using Abstract Syntax Notation 1 (ASN.1) [3], and is typically transferred using a subset of ASN.1 Basic Encoding Rules [11].
Your points are all right on. If you actually read the link in the previous post, you would see that Netscape failed on all of those measures, while OpenLDAP excelled. The Netscape servers would crash at least twice a week and their databases went corrupt more often than that. The OpenLDAP servers never crashed and never corrupted the database. And that was all in a Kerberos-enabled environment - security features in OpenLDAP are second to none.
All it consists of are subjective claims ("very very fast") with no facts or any points of reference. That is not "information" that is "groundless opinion."
Show us the "Netscape Directoy" server that can handle 200,000 clients, and show us the operation mix, database size, representative data, network topology, and server configurations. *That* would be "Informative."
The previous poster is right on. Data distribution in LDAP is a hack, accomplished using the poorly specified concept of "referrals" that was added as an afterthought to LDAPv2 and is still underspecified today in LDAPv3.
By throwing out all of the design intelligence that went into the X.500 DSP protocol, defining how server-to-server communication works, the LDAP folks have set themselves back another decade and are still struggling to define the controls and extensions to provide the distribution features that are needed (and were already provided, in real X.500).
All the LDAP servers that implement chaining for management of data distribution have to use proprietary techniques because the LDAP standard is so weak it doesn't provide any meaningful guidance here.
Slashdot Mirror
Good choices, all. Airwolf got me interested in helicopters; before that I thought they were just ungainly oversized bugs. But hey, a flying machine that can go supersonic and still turn on a dime, armed with cool missiles and armor - that's slick. Especially since most of the technology they showed was actually feasible to mount into a helicopter. (KnightRider, on the other hand, was always just something to smirk at...)
Hm, I gotta get hold of the Space 1999 DVDs, it's been ages since I've seen Barbara Bain...
Not only do trademarks have to be registered in a specific field, but they have to be registered in a specific class of product or service. Still, the guiding principle is whether use of the mark will cause confusion for the public.
When I registered my trademark for my band (Highland Sun, http://www.highlandsun.com/ I received a letter from someone who was registering a mark for "Highland Sun Farms" - a horse ranch somewhere (in Kentucky IIRC) asking me to stop using the name as it infringed on his. Even though our two uses of the mark (including graphical design/logo) are completely unrelated, his trademark attorney advised him to contact me. (For a variety of reasons, my claim to the mark had sufficient merit, so I am still using it to this day.) Much as I hate anything associated with IP law, I recognize that that guy was just doing his job, protecting the value of his client's mark.
Having just read through about a half of the debian trademark debate, I'm glad I don't have to wrestle with it. And I give props to the guys who are standing on their principles. I can see valid points on multiple sides of the debate.
1) The guiding principle of Free Software is to give users the freedom to use and distribute the software, without unreasonable restrictions. There are a few restrictions of course, like - you must not claim the software as your own if you didn't actually write it - you must attribute it to the actual authors. In other words, you are prohibited from being a jerk about it.
2) The basic premise of trademarks is that there is value in a name, and that value and name must be protected. As such, use of a trademarked name is tightly controlled, pretty much by definition. (If you're not going to worry about controlling use of the name, then there's no point in getting the trademark registration in the first place.)
I believe if you carry the principles of the Free Software Foundation to their ultimate conclusion (reductio ad absurdum, in this case) then they are incompatible with all three forms of Intellectual Property - copyrights, patents, and trademarks. Because in order to use a piece of software, you need a handle with which to refer to it. Even if I give you the code for free, if I don't let you call it by the same name that other people call it, then your use of the software is severely hampered. e.g. "I just wrote this C compiler. I call it the GNU C compiler. You're welcome to use it too, but you can't use the same name, because I'm afraid you'll make modifications to it that harm its quality, and I don't want your version to harm the reputation of my original code. So you're not allowed to use the words "GNU", "C" or "compiler" in any combination in reference to your copy of it."
Fortunately, nobody needs to carry it to that extreme, because the FSF's goal isn't just Freedom for the sake of some abstract philosophical condition, the goal is FAIRNESS. That's why reasonable restrictions are part of the GPL and other FAIR licenses. "You may distribute modifications of this code, but you must clearly mark your modifications. You must use a different version number. etc..." That's fair - it avoids people confusing your copy for the original, but it allows you to keep referring to it by essentially the same name, so that when people see "gcc-4.0.5-hyc" they have some idea that "oh, this is a customized version of gcc" and they don't have to ask themselves, "wtf is this buffalo-chip-code-generator doing on my distro and why should I care?"
Exchange may work in a corporate environment, but it's certainly not a reasonable solution for a home user.
Thanks for the info. I'm not about to switch back, but it's nice to know there was a fix.
You're missing the point. Even sorting messages into subfolders (there are about a dozen subfolders in that archived Inbox, I collapsed the view so they're not in the screenshot) only postpones the inevitable.
Is it so totally beyond your comprehension that someone may legitimately receive 16,000+ messages all of a particular topic (e.g., a mailing list) that they'd want to save in one place? That is the point of a mail archive, after all.
The fact that this example is the Inbox is irrelevant. It could have just has easily been my archive of the gnu-gcc mailing list or anything else.
Don't be an asshole. Why would I make this shit up?
Try storing more than 16383 items in one folder. It won't let you. Here's a screenshot of my archive.pst Inbox, just to demonstrate:
http://www.highlandsun.com/hyc/ol2000max.png
If you're routinely putting tens of thousands of items into PST files, you're going to hit a wall, sooner or later, and it has nothing to do with filesystem/disk space.
Yeah, I used to use Outlook 2000. I switched to Mozilla after my Outlook archive.pst died, it hit 16384 items and wouldn't accept any more. So much for archiving... The Mozilla calendar is definitely in sad shape. The Mozilla POP3 client was too, but I bludgeoned the code until it did what I want. Don't have time to do the same for calendar, unfortunately.
Actually most of this work has been going on throughout Carly's reign. She took over in '99, HP's first patent on the stuff was issued in 2000.
0 1/1823256&tid=173&tid=14
HP Nanotech web page
And the design itself has already been covered here a few times...
http://science.slashdot.org/article.pl?sid=05/02/
The research had probably been going on long before Carly arrived. The biggest connection you could draw between the two is, she didn't axe it during her reign...
In OpenLDAP 2.3 (which has been in beta for a few months and is due for a public release in a few days) the full configuration is editable via LDAP, so you no longer need to restart the server to tweak ACLs, add schema, or reconfigure indexing. In fact you can generate a complete server configuration via LDAP - you can add new backends and start them up and shut them down on the fly.
re: decent GUI tools - yes, this is a problem, but you have to frame it correctly - it is a problem with LDAP software in general. You shouldn't *need* a custom console to configure the service, you should be able to do everything through the basic protocol, regardless of how you access the protocol - command line, standalone GUI, or web application. Most site admins will always need a combination of these tools - command line tools for automated/batched, bulk access and for trivial incidental operations, a GUI to aid in visualizing an overview of the data, and a variety of customized web forms for the day-to-day trivia like resetting users' passwords. A custom console may be helpful, but the ones I've seen so far are overkill for day to day administration, and not flexible enough for real problem resolution. It will be nice to work toward a generic console that can address all of these needs, but I think we'll be stuck writing one-offs for some time yet.
I would never advocate replacing LDAP with DAP, that wouldn't solve anything anyway. My point is that LDAP is only a client to server access protocol, but people thought they could use it for everything and forget about the problems that DSP and DISP were designed to solve. People are trying to do distribution now with LDAP, and beating their heads against the walls.
As a simple example - in X.500, two servers (A and B) that trust each other can establish a DSP session between themselves. If an authenticated client request comes in to server A but data is needed from server B to satisfy the request, the server A can securely chain the request on behalf of the client without any fuss.
In LDAP, if the same situation arises, a couple of things can happen:
server A can return a referral to the client. The referral mechanism doesn't address how to handle security in a referral though. Possibly the two servers support a disjoint set of authentication mechanisms. Possibly one server requires TLS and the other doesn't; that information isn't encoded in the referal. Possibly the referred server is behind a firewall that the client can't cross. There are any number of problems here that will prevent the client from successfully concluding the request. In the absence of any policy information (and where does that come from?) the client may have no choice but to chase the referral using a plaintext Simple Bind. The referral might point to a rogue server, which will then take the client's credentials and feed that info to who knows where.
There's another possibility, for a server that implements chaining via LDAP: in this case you might be able to create the same kind of trusted inter-server session that DSP allows. But since LDAP doesn't have server-to-server support built in, that session needs to be established by means of Controls and Extended Requests. One of the big problems here is that the LDAP standard cannot distinguish between client-server and server-server communication. Any client could legitimately use the same Controls that are intended to facilitate server-server communication; when server A receives a request decorated in this manner, there's no clear way for the server to determine how to progress the request. For example, the Proxy Authorization control, which essentially allows one to say "I'm identity A but please perform this operation with the privileges of identity B." This capability is a key requirement for secure server to server chaining, but if a client issues a request with Proxy Authorization attached, the correct behavior for the server is ambiguous.
Personally I think you just like showing off that you knew LDAP was descended from OSI DAP, and didn't mean to get caught up in this conversation.
Actually, I distinctly remember waking up this morning and thinking to myself "ah, what a nice day. I hope I can get into an argument about LDAP with someone on slashdot, that would be just perfect." Must've been the full moon last night.
Ah yes of course. NCSA Mosaic was just a copy of MS IE, then. Oh wait, Mosaic predated Microsoft Internet Explorer by at least two years. Hmmmmm....
Well said.
Thanks for an interesting read. My impression of Novell eDirectory mostly agrees with yours. A couple of points, not to detract from your excellent post:
OpenLDAP 2.2 back-hdb supports subtree renames. The lack of this feature has been an obvious, longstanding deficiency but that was corrected over a year ago.
Replication strategy - I think this may be an irreconcilable religious issue. I don't believe a feature that allows unresolvable update conflicts is suitable for use, others are willing to live with it because the possibility for problems to arise is usually low.
Actually, I am a founder of Symas Corp. And I made no effort to hide that fact, you can see my associations all over my personal web site (which is linked on all of my slashdot posts) as well as the relevant Symas and other web sites.
Your comparison to Microsoft's "Get The Facts" campaign is way off base. The real point of my posting here is that you are passing anecdotes about things nobody can meaningfully assess or prove on their own.
The information I refer to on the Symas benchmarking page is provable by anybody. The OpenLDAP code can be downloaded by anybody. Anybody can download DirectoryMark and set up the same tests. We documented the hardware we used so that you can have meaningful points of reference for every data point.
Whether you think Symas has a product that's relevant to you is not my concern. I don't care a whit if you buy anything from us or not, and none of my posts said "buy our stuff!"
Been there, done that. At least 5 years ago the first time, and many times since then. Perhaps if you had asked for help you would not have had such a hard time with it. That *is* one of the benefits of working in an open source community after all.
Your reading skills are weak, then. That page refers to the May 2000 study merely to provide a point of reference. The results on that page are all only a couple of months old.
I've already proved you wrong once, haven't you had enough yet?
"Referrals work." Only in a fantasy world where security and authentication are unimportant, and where firewalls don't exist.
The fact that there are still people submitting drafts to the LDAPEXT Working Group to define controls and extensions for real distributed operation is proof that the rest of the world is not as happy as you are with LDAP's server to server capabilities today. If you can't see that, it's no burden to me.
I don't see a major issue here
That's OK for you to say, because you've already considered the factors that are important to your individual use case. But LDAP is intended to fit a multitude of use cases and for the protocol designers to take this stand is grossly irresponsible.
You blithely say that "Techniques for bridging between databases" are well understood, but you don't notice that they only work when the entire system and all connections work well. When any component fails or misbehaves, the behavior of the entire system goes into a randomizer. The fact is that in any complex network, the probability is 100% that some component will be failing or misbehaving for a non-trivial amount of the system's operational life. Without paying careful attention to these details, the design will collapse in the face of those outages.
The fact that the LDAP working groups are still struggling with these distribution issues today is a testament to my point - the original LDAP guys didn't do their homework, and now that LDAP has crept in all around the network, the rest of the world is paying the price.
Yet another mindless raving rated as "Insightful" - where do you guys get this stuff?
.. it is high quality from its core to its exterior" as *Insightful* ?? There is ZERO insight here.
The above post is a stream of empty claims and not even a hint of factual support. How can you rate someone saying "I haven't looked at the code yet
Nobody here knows what kind of server the Netscape guys were talking about, what those 200,000 clients were doing, or what the directory data looked like. We have No Insight into what that claim means.
But you can look here http://www.symas.com/benchmark.shtml and see charts derived from documented benchmark procedures that You Yourself can repeat and verify, showing that Netscape's performance drops off FASTER than OpenLDAP's as the number of clients increases. You want INSIGHT - doing systematic tests and publishing the tests so that others can verify the results is how you get it. Not by factless gushing from a fanboy who has never seen the code in question.
http://www.ietf.org/rfc/rfc2251.txt?number=2251
Section 4 "Elements of Protocol" (page 9)
Your points are all right on. If you actually read the link in the previous post, you would see that Netscape failed on all of those measures, while OpenLDAP excelled. The Netscape servers would crash at least twice a week and their databases went corrupt more often than that. The OpenLDAP servers never crashed and never corrupted the database. And that was all in a Kerberos-enabled environment - security features in OpenLDAP are second to none.
In what way is the above post "Informative" ??
All it consists of are subjective claims ("very very fast") with no facts or any points of reference. That is not "information" that is "groundless opinion."
Show us the "Netscape Directoy" server that can handle 200,000 clients, and show us the operation mix, database size, representative data, network topology, and server configurations. *That* would be "Informative."
*THIS* is informative: http://www.symas.com/benchmark.shtml
Those are real facts that anybody can replicate using their own hardware.
What you're spewing is just noise, not information.
Sun has backpedaled on Linux so many times; if anyone still considers using SunOne on Linux today they've got to be a complete and total moron.
(Leaving aside the obvious question of using SunOne for anything at all...)
The previous poster is right on. Data distribution in LDAP is a hack, accomplished using the poorly specified concept of "referrals" that was added as an afterthought to LDAPv2 and is still underspecified today in LDAPv3.
By throwing out all of the design intelligence that went into the X.500 DSP protocol, defining how server-to-server communication works, the LDAP folks have set themselves back another decade and are still struggling to define the controls and extensions to provide the distribution features that are needed (and were already provided, in real X.500).
All the LDAP servers that implement chaining for management of data distribution have to use proprietary techniques because the LDAP standard is so weak it doesn't provide any meaningful guidance here.