directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Discussion on porting X.500 ACIItem to LDAP
Date Wed, 14 Sep 2005 20:39:33 GMT
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:
> >
> >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 :

	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 :


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

View raw message