On Wed, 2005-09-14 at 16:09 -0400, Alex Karasulu wrote: > Ersin Er wrote: > > >Hi all,
Hi ersin_er ! > >You can find ASN.1 syntax for X.500 ACIItem here: > >http://docs.safehaus.org/display/APACHEDS/ASN.1+syntax+for+X.501+ACIItem > >Now I'll talk about some issues concerning it. Great job you did ! > >* 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) } If you do that, you will greatly improve the LL grammar ! You will just have to substitute this enumeration at the top level like this : ACIItem ::= SEQUENCE { identificationTag DirectoryString { ub-tag }, precedence Precedence, authenticationLevel ENUMERATED { none (0), simple (1), strong (2) }, ... > >* 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. > > > > > This is a string essentially of ascii 0's and 1's right? If so this is > ok for me too. For the ACI representation remember this is just for the > user to be able to tell the server what is toggled. So this should be > easy for the human to manipulate. It *may* not be what is used for the > runtime representation. Meaning for the runtime representation we might > prefer to use an int value with these bits at certain indices (perhaps > the choices denoted by X.501). If you are talking of Java implementation, you can then use the BitString class : /asn1/ber-new/src/java/main/org/apache/asn1new/primitives/BitString.java > > >* 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). > > > > > > > Look there is not LDAP RFC defined for this. Meaning no grammar in ABNF > has yet been defined. The guys writing the ietf draft would have to do > what we are doing now. They are going to try to use RFC 3641 to figure > out an ABNF for the ACIItem in X.501. Actually, if you have spaces in all those Names, they are suppose to be escaped with a \. But I agree that it's a PITA to parse. It could be better to use " " to surround them, as soon as " is escaped (I think it is supposed to be escaped). May be we are just establishing the RFC, right here ? ;-) > > They are going to run into several problems because RFC 3641 and 3642 > are not perfect. They are not designed to take parser technology > intricacies into account so they often fall short. In the end many > protocol specifications wind up deviating from 3641/3642 > recommendations. This is natural. And this is why there name are RFC (Request for Comment) :) May be we can comment those RFC? Again, great job :)
