[Kolab-devel] New attributeType kolabTargetFolder for objectClass kolabSharedFolder

[Jeroen van Meeuwen (Kolab Systems)]

On 2012-03-07 20:47, Martin Konold wrote:
> Am Mittwoch, 7. März 2012, 18:38:46 schrieb Jeroen van Meeuwen:
>
> Hi Jeroen,
>

Hi Martin,

>> entries the kolabSharedFolder objectClass.
>> With a kolabTargetFolder
>>
>> Thoughts? Comments? Questions? Gripes?
>
> I think you gave a very valid rational for the need of such an 
> attribute in
> large organisations.
>
> Some comments though:
>
> 1. Did you consider to use a kolab group account in order to fullfill 
> the
> requirement?
>

If by a "kolab group" you mean a distribution list - the implied 
delivery of a copy to individuals is not suitable for what is sought to 
be implemented through shared folders - adding a new person to the group 
doesn't get them the archives, and groups are sometimes tens of 
thousands of people, with duplication becoming a storage nightmare, if 
you will.

If by a "kolab group account" you mean something of a user/shared 
mailbox, I'm really not a fan of these.

> 2. I prefer to call these folders "public folders" today instead of 
> "shared
> folders".
>
> Rational: Shared folders are folders of individual or group users
> which carry ACLs which grant access to other users/groups beyond the 
> owner.
>
> (Yes I am aware of the fact that I wrongly introduced this term in 
> Kolab.)
>

I've heard this rationale before and I don't agree.

I feel you and others are misconstruing "shared folders" solely for 
"user folders that are shared", instead of it's intended purpose; 
"folders outside the personal name-space meant to be shared", and are 
therefore coming up with something different from what these things are 
called on the lowest possible level in this context, the Cyrus IMAP 
mailbox database.

Feel free to call these things whatever floats your boat, I'm sticking 
to what these things have been called since the early '90s.

> 3. I am in general fine with adding the new attribute
> kolabTargetFolder to the objectclass kolabSharedFolder.
>
> 4. The definition of the new attribute should imho be improved 
> because it is
> hard to fix it later.
>
> +attributetype ( 1.3.6.1.4.1.19414.2.1.8
> +  NAME 'kolabTargetFolder'
> +  DESC 'Target for a Kolab Shared Folder delivery'
> +  EQUALITY caseIgnoreIA5Match
> +  SUBSTR caseIgnoreIA5SubstringsMatch
> +  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
> +  SINGLE-VALUE )
>
> I think that limiting the names of the target folders to ASCII is not 
> a good
> idea (IMAP already allows many non ASCII chars) and doing non case 
> sensitive
> matches is not suitable.

I was actually thinking of just allowing everything UTF-8 permits - in 
LDAP I suppose this needs to be escaped, and in IMAP it needs to be 
encoded to UTF-7.

> Instead I propose to allow for all valid IMAP
> foldernames and do case sensitive matches. With regards to matching I
> want to refer to the newest LDAP RFCs.
>

I hadn't given this much thought, actually, but now that I do, you're 
probably right. Note though the value is a read-only value, after having 
searched for the entry - as opposed to a lookup value.

> I think 1.3.6.1.4.1.1466.115.121.1.15{512} would be fine but it would
> require that you change the syntax slightly as the Directory String 
> does not allow
> zero-length strings. On the other hand PrintableCharacter or
> PrintableCharacter might be alternatives.
>
> Proposal (based on Directory String):
>
> attributetype ( 1.3.6.1.4.1.19414.2.1.8
>   NAME 'kolabTargetFolder'
>   DESC 'Target for a Kolab Shared Folder delivery'
>   EQUALITY caseExactMatch
>   SUBSTR caseExactSubstringsMatch
>   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{512}
>   SINGLE-VALUE )
>

This looks entirely reasonable, I'll work with this instead of my 
patch.

> Please also check with RFC 3501 "5.1.3.  Mailbox International Naming
> Convention" which refers to RFC 2152 (UTF-7).
>
> While the encoding of a Directory String is UTF-8 of course IMAP 
> requires a
> conversion to UTF-7 whenever an IMAP mailbox (i.e. a folder) is 
> refered.
>
> (I am not aware that OpenLDAP direclty supports a UTF-7 string 
> syntax)
>

Inserting a UTF-7 name / path for a folder wouldn't really help anyone 
anyway, I suppose.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08