> Hi Ersin, > > 2005/9/15, Ersin Er <[EMAIL PROTECTED]>: >> >> * 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
