[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Test operations

Morteza Ansari wrote:

Howard Chu wrote:

Morteza Ansari wrote:

I definitely second this, SunDS also supports this control (I am not sure if the two implementations are 100% compatible though). Converging on this would make app's developers job easier.

Interesting, considering that this draft hasn't progressed very far and has no OIDs assigned. How exactly do you expect anyone to write a compatible implementation? And of course "It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress.""

Having a "standard" would be great, but "similar" implementations is better than nothing! If the implementation of SunDS and/or Netscape are interoperable and we have one that is closely related to that it is better than nothing. I know, I have low expectations!

I guess you have a point; if they really are interoperable then it's probably a win. But a loose reading of your first sentence sounds like heading down a path for which Microsoft is so well known...

The old draft mentioned support for X.500 access controls, but the latest draft (rev 06, 14 July 2000) doesn't mention it any more. All of which may be academic since the LDAPext working group shut down and this draft expired in January 2001.

This draft http://www.ietf.org/internet-drafts/draft-legg-ldap-acm-bac-03.txt is at least current, and the X.500 models it describes have already been widely implemented by X.500 vendors. In this respect, it doesn't have the shortcomings of the LDAPext model (which among other things doesn't allow for value-specific rights).

I don't know what Steven's plans are regarding moving this forward at IETF, but I have a feeling it probably won't get adopted by most vendors. It is unfortunately, but I think collectively we as a community failed to agree on ACL and replication and now everyone has their own implementations with little hope of ever getting to a standard solution.

Speaking of which, a brief digression to an ACL rights model I toyed with a couple years ago, borrowing a bit from DG AOS...
P - Permit - allows changing the ACLs on an object
A - Append - allows creating new objects
R- Read
M - Modify
E - Erase
S - Search
N - Name - allows renaming objects

(PARMESN, a robust and flavorful access control model. Think it's too cheesy?) (OK, ok, I apologize for making anyone read that...)

Before going off and implementing an expired draft, it would be nice to understand why the model never made it beyond draft status. Surely it does not reflect well on the described model for it to have been abandoned by the authors. Nor would it reflect well on us to claim support for what can only be considered an incomplete specification.

From what I recall it was a combination of too much discussions and vendors needing a solution for their products which resulted in many un-interoperable(?) solutions.

By no means I am suggesting implementing getEffectiveRights control solves all ACL problems. However, if we are going to implement soemthing like that, we might as well implement the same one that other vendors have implemented (assuming there are no major issues with it).

Right. As to that, someone must have a spec for what Netscape and/or Sun actually implemented. That would be a good starting point, but we already know that OpenLDAP's ACL mechanism has more access control factors than can be expressed in the LDAPext drafts, so unless we extend the spec we can't offer accurate info to a client. And if we do extend it, then we can't guarantee interoperability any more. So we're left with the choice of being compatible but giving out wrong information, or being accurate but not being compatible. Personally I would choose not to sacrifice accuracy/correctness.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support