Ersin Er wrote:
This is really a big spec when you think that a
Set of SubtreeSpecifications is only a small part of the grammar..
I can change the grantsAndDenials to recognize a string of certain
number
of 0's and 1's something like '10101010'B. However Trustin will have to
write a lot of bitwise code to handle this component in his ACDF. If we
choose this way we must exactly determine which fields are necessary for
ldap while it's not a flexible structure.
If you write a string, you will have to put all the bits. It's a good
idea to suppress some of the bits, but keep in mind that it's a better
idea to keep the offset of each bit, instead of renumbering them.
It's a good idea to keep unused bits reserved. Then we'll be compatible
with X.501 and save space a lot. I liked this.
+1 to use the bit string index in the spec as the index into the bit
string for all these reasons.
Handling the bits could be something simple if we use internally the
BitString we have in ber-new, assuming we add a constructor that take a
String.
Emmanuel I would like to avoid using ASN.1 constructs as much as
possible in the heart of the server. We can use a simple object to
represent the bit string that does not involve ASN.1. We are not going
to be communicating the ACIItem in its ASN.1 form over the wire. Over
the wire, the ACIItem is just another attribute value. In an X.500
server the ASN.1 representation would have significance where the ASN.1
is used for the transmission syntax and even the syntax for storing the
ACIITem but this does not hold for LDAP.
If Trustin provides me a constructor that takes a String then i'll not
care if he uses your stuff or his own :-) But we should first be sure if
we'll use bit-list or bstring form. After Alex and Trustin says final
thoughts i'll finish it up.
Can you elaborate on the differences between bit-list and bstring? How
would these differences manifest themselves in a Java representations of
the grantsAndDenials?
Alex
