directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: Discussion on porting X.500 ACIItem to LDAP
Date Thu, 15 Sep 2005 00:19:21 GMT
Hi Ersin,

2005/9/15, Ersin Er <>:
> * We need to determine what the ProtectedItems component can include
> concerning LDAP.
> As we talked with Alex, we can omit:
> context

Actually I don't understand what 'context' is in X.501. Could you help me 
out here?

* 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.

I don't think we need optional UID for now and I don't see any good use of 

* 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:

That's what I've done exactly in my data model. But I'm not sure it is right 
to omit 'signed' value. X.501 specification doesn't describe the term 
'signed' in detail, so I cannot decide it.

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

All grants and denials are applicable to LDAP IMHO.

* 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.

They cannot be combined with bitwise operations as you see from their 
values. (or these numbers describes 'bit offset'?) It would be nice if we 
can change it to SEQUENCE for simpler implementation.

* 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).

+1 if it makes your life easier. 

I also want to talk about using Retroweaver to get benefits from Java 5 
syntax sugar. Retroweaver will help us to develop the application with 
JDK1.5 and make it run in JDK1.4 via byte code manipulation.

what we call human nature is actually human habit

View raw message