Ersin Er wrote:
Hi all,
As you'll see we're doing some ACI stuff for ApacheDS and LDAP in general.
ACIItem is the core component of ACI model of X.500 (x.501 in particular)
and will be so for LDAP. However, we need to decide what features of
ACIItem fit to LDAP model.
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.
* We need to determine what the ProtectedItems component can include
concerning LDAP.
As we talked with Alex, we can omit:
Right you just corrected this as being the 'contexts' feild instead.
* 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.
* 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.
I'm not sure about this ASN.1 syntax and correction is welcome.
* We need to determine which bits in GrantsAndDenials fit to LDAP. Trustin
and I currently include them all.
Yah some can go. Again let me nestle the X.501 spec tonight with a cup
o' tea.
* 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).
* 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.
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.
LDAP for example in 2251 deviates from BER encoding rules and states it
does this for ease of implementation. So its common for protocols to
tweak but clarify why they tweak or deviate from recommendations like GSER.
So go ahead and add some delimiters that make life easier for
implementing the parser. Just make sure your delimiter choices do not
prevent the correct parse of other grammar constructs. For example do
not use a comma to separate a list of DNs ;).
Also document what exceptions you have devised. We really are going to
need to have the ABNF grammar so users can add ACI Items to subentries.
So they are going to need your grammar description. Hopefully we can
also show them some examples when we are done so users can see how to
control access to entries in APacheDS.
Thanks Ersin,
Alex
