2005/9/15, Ersin Er <[EMAIL PROTECTED]>:
Actually I don't understand what 'context' is in X.501 . Could you help me out here?
I don't think we need optional UID for now and I don't see any good use of it.
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.
All grants and denials are applicable to LDAP IMHO.
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.
+1 if it makes your life easier.
* 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 it.
* 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.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
