directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Discussion on porting X.500 ACIItem to LDAP
Date Wed, 14 Sep 2005 16:35:01 GMT
Hi all,

As you'll see we're doing some ACI stuff for ApacheDS and LDAP in general.
ACIItem is the core component of ACI model of X.500 (x.501 in particular)
and will be so for LDAP. However, we need to decide what features of
ACIItem fit to LDAP model.

You can find ASN.1 syntax for X.500 ACIItem here:
Now I'll talk about some issues concerning it.

* We need to determine what the ProtectedItems component can include
concerning LDAP.

As we talked with Alex, we can omit:

* We need to decide if we can really have an optional UID part of an
NameAndOptionalUID used in UserClasses component. I did not make the
parser recognize this part and Trustin also did not include this field in
the API. If we decide so that it can just be a name then I can change the
spec and grammar to replace NameAndOptionalUID with a DistinguishedName.
You can checn RFC 2252, section 6.21 for details.

* We need determine which fields of the AuthenticationLevel component is
need for LDAP. Trustin has cut it so that it became only an enumeration of
values none (0), simple (1) and strong (2). If you look at the ASN.1
expression it has much more. If we'll change the spec for LDAP to only
include this enumeration then I can update the spec like this:

   AuthenticationLevel ::= ENUMERATED { none (0), simple (1), strong (2) }

I'm not sure about this ASN.1 syntax and correction is welcome.

* We need to determine which bits in GrantsAndDenials fit to LDAP. Trustin
and I currently include them all.

* We need to determine the way we store a BIT STRING for GrantsAndDenials.
I preferred to use bit-list syntax while it's really clear (but space
consuming). You can check RFC 3641, section 3.5 for details.

* Finally I'm not sure if we can surround NameAndOptionalUID,
AttributeType, AttributeTypeAndValue, DistinguishedName and
DirectoryString with double quotes. Adding them makes parsing easy and
help readibility. RFCs do not all agree on this (or may be they just do
not mention).

These are what I'm not sure about. Ofcourse you can futher extend the


-- Ersin

View raw message