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 Wed, 14 Sep 2005 20:40:26 GMT
> Ersin Er wrote:
>>* 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.
> Hmm ok I need to look into the X.501 spec again and keep an eye on these
> details.

This NameAndOptionalUID type is mentioned in RFC 2252 as:

6.21. Name And Optional UID

   ( DESC 'Name And Optional UID' )

   Values in this syntax are encoded according to the following BNF:

      NameAndOptionalUID = DistinguishedName [ "#" bitstring ]

   Although the '#' character may occur in a string representation of a
   distinguished name, no additional special quoting is done.  This
   syntax has been added subsequent to RFC 1778.


However, I do not know if it has any use in LDAP. And I do not understand
the RFC writers saying the last sentence here: Although the '#' character
may occur in a string representation...

>>* 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)
>> }
> I think this is good since in LDAP land we have either none (anonymous),
> simple or sasl auth which basically translates to "almost" strong auth.

The we simple do not need "bacisLevels", "other", "localQualifier" and
"signed" fields ?

When we change the spec so that it becomes an Enumeration instead of an
CHOICE or whatever else, we do break some compatibility with X.500. Our
spec will not be a subset of X.501 spec then. If this is not a problem
than this simple scheme is better for me.

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

Trustin's implementation also uses an object for each field, so our run
time representation is not just a list of bits. But I'm ok with this while
it's so clear.

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

For example, RFC 2253 does not ever mention, RFC 3641 implies and RFC 3642
states that a DistinguisedName is surrounded with dquotes. Ofcourse I'll
prefer the dquoted one :-)

I'll write all the abnf as soon as possible.

-- Ersin

View raw message