directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Re: Discussion on porting X.500 ACIItem to LDAP
Date Thu, 15 Sep 2005 06:00:27 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?

So we omit :-) What I've seen from figures is that they are subcomponents
of attributes and I do not know more.

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

I'm always ok with cuts ;-) I really do not think we'll ever use it. Then
I'm changing it to a DistinguishedName, ok?

> * 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 clearify this because it'll change the spec seriously.

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

>From RFC 3641:
BitStringValue = bstring / hstring / bit-list

The <bit-list> rule encodes the one bits in the bit string value as a
comma separated list of identifiers.

The <bstring> rule encodes each bit as the character "0" or "1" in order
from the first bit to the last bit.

The <hstring> rule encodes each group of four bits as a hexadecimal number
where the first bit is the most significant.

I chose the bit-list one while it's really clear. We need to determine
approaches for both model and grammar. Wating for a few more comments
about this.

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

Ah yes, I thought about it when I saw we have a lot of

   ArrayList children = new ArrayList();

where children is composed of ExprNodes in fact. So it'll really be
understandable and type safe to be able to write:

   List <ExprNode> = new ArrayList<ExprNode>()

Many other benefits ofcourse..

> Trustin

-- Ersin

View raw message