Hi all,
> > * We need to determine which bits in GrantsAndDenials fit to LDAP. Trustin
> >> and I currently include them all.
> >
> >
> > All grants and denials are applicable to LDAP IMHO.
> >
> > * We need to determine the way we store a BIT STRING for GrantsAndDenials.
> >> I preferred to use bitlist syntax while it's really clear (but space
> >> consuming). You can check RFC 3641, section 3.5 for details.
> >
> >
> > They cannot be combined with bitwise operations as you see from their
> > values. (or these numbers describes 'bit offset'?)
In ASN.1, the numbers is the bit offset.
> It would be nice if we
> > can change it to SEQUENCE for simpler implementation.
>
> >From RFC 3641:
> 
> BitStringValue = bstring / hstring / bitlist
>
> The <bitlist> rule encodes the one bits in the bit string value as a
> comma separated list of identifiers.
>
> The <bstring> rule encodes each bit as the character "0" or "1" in order
> from the first bit to the last bit.
>
> The <hstring> rule encodes each group of four bits as a hexadecimal number
> where the first bit is the most significant.
> 
>
> I chose the bitlist one while it's really clear. We need to determine
> approaches for both model and grammar. Wating for a few more comments
> about this.
The solution Ersin_er as choosen as an advantage : readibility.
At a certain point, however, one problem will arise : all this GSER is
very verbose. We are loosing one main advantage of ASN.1 encodeing,
compactness. It's almost certain that the ACIItem control will represent
at least half of any PDU, and may be much more ! For instance :
{ identificationTag \"id1\" , precedence 114, authenticationLevel
basicLevels:{ level none, localQualifier 23, signed FALSE },
itemOrUserFirst itemFirst:{ protectedItems{ entry, attributeType
{ 1.2.3, ou }, attributeValue { ou=people, cn=Ersin }, rangeOfValues
(cn=ErsinEr) }, itemPermissions { { userClasses {allUsers, userGroup
{ \"1.2=y,z=t\", \"a=b,c=d\" }, subtree { { base \"ou=people\" } } },
grantsAndDenials { denyCompare, grantModify } } } }}
takes 391 bytes (and only because we only have ASCII chars !). This is
huge ! 90% of all those bytes are identifier (the T part of TLVs).
I don't know if it's a big problem, but this is something we might like
to consider.
An option could be to adopt this encoding from now on and allow another
one, more compact (again, using ASN.1 to encode this kind of control
could be an option).
wdyt ?
Emmanuel.
