[Kroupware] LDAP address book schema suggestion

Miles Lott kroupware@mail.kde.org
Sun, 29 Sep 2002 12:17:44 -0500


Here is a version of the schema originally written for
phpGroupWare that I would now be using for my new
project, GroupWhere.  This has been modified to, hopefully,
be closer to what Tobias outlined.

# $gw : gwcontact.schema,v 1.0 2000/07/29 01:53:16 milosch Exp $

# REQUIRED
attributetype ( 1.3.6.1.4.1.9610.100
	NAME 'gwContactTypeId'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16}
	SINGLE-VALUE )

# REQUIRED
attributetype ( 1.3.6.1.4.1.9610.101
	NAME 'gwContactCatId'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{16})

# REQUIRED
attributetype ( 1.3.6.1.4.1.9610.102
	NAME 'gwContactAccess'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
	SINGLE-VALUE )

# REQUIRED
attributetype ( 1.3.6.1.4.1.9610.103
	NAME 'gwContactOwner'
	EQUALITY numericStringMatch
	SUBSTR numericStringSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16}
	SINGLE-VALUE )

# BELOW ARE OPTIONAL
attributetype ( 1.3.6.1.4.1.9610.105
	NAME 'gwMiddlename'
	SUP name )

attributetype ( 1.3.6.1.4.1.9610.106
	NAME 'gwPrefix'
	SUP name )

attributetype ( 1.3.6.1.4.1.9610.107
	NAME 'gwSuffix'
	SUP name )

attributetype ( 1.3.6.1.4.1.9610.108
	NAME 'gwAudio'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.4{25000} )

attributetype ( 1.3.6.1.4.1.9610.109
	NAME 'gwBirthday'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )

attributetype ( 1.3.6.1.4.1.9610.110
	NAME 'gwTz'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.9610.111
	NAME 'gwGeo'
 	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.9610.112
	NAME 'gwUrl'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )

attributetype ( 1.3.6.1.4.1.9610.113
	NAME 'gwPublicKey'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )

attributetype ( 1.3.6.1.4.1.9610.115
	NAME 'gwAddressLabel'
	EQUALITY caseIgnoreListMatch
	SUBSTR caseIgnoreListSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

attributetype ( 1.3.6.1.4.1.9610.131
	NAME 'gwPreferPhone'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.9610.114
	NAME 'gwAddrType'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )

attributetype ( 1.3.6.1.4.1.9610.133
	NAME 'gwMailAddr'
	SUP mail )

# gwContact Objectclass
objectclass	( 1.3.6.1.4.1.9610.201
	NAME 'gwContact'
	DESC 'GroupWhere Contact Entry'
	MUST(
		uid $ uidnumber $ gwContactTypeId $ gwContactCatId $
		gwContactAccess $ gwContactOwner )
	MAY ( cn $ givenname $ sn $ gwMiddlename $ gwPrefix $
		gwSuffix $ gwAudio $ gwBirthday $ gwTz $ gwGeo $
		gwUrl $ gwPublicKey $ o $ ou $ title $
		gwAddressLabel $
		gwPreferPhone $
	)

# gwContactPhone Objectclass
objectclass ( 1.3.6.1.4.1.9610.202
	NAME 'gwContactPhone'
	DESC 'GroupWhere Contact Entry telephone number'
	MUST ( objectclass $ uid )
	MAY ( telephonenumber $ gwPhoneType )

# gwContactAddr Objectclass
objectclass ( 1.3.6.1.4.1.9610.203
	NAME 'gwContactAddr'
	DESC 'GroupWhere Contact Entry address'
	MUST ( objectclass $ uid )
	MAY ( gwAddrType & postOfficeBox $ extended $
		street $ locality $ region $ postalCode $
		country $ label $ friendlyCountryName $ co
	)

# gwContactEmail Objectclass
objectclass ( 1.3.6.1.4.1.9610.204
	NAME 'gwContactEmail'
	DESC 'GroupWhere Contact Entry email address'
	MUST ( objectclass $ uid )
	MAY ( gwMailType $ gwMailAddr )


Tobias Koenig wrote:
> 
> Hi,
> 
> I'm the current maintainer of kaddressbook and I'm reading this list
> since 2 weeks. In this time there weren't discussed any details concerning
> the communication between kaddressbook and the kolab server.
> 
> At first I wan't to mentioned, that accessing vCards over SMTP/IMAP is a
> ugly way, because these protocols aren't flexible enough for easy accessing
> the contacts. I know it's too late for the release, but IMHO using webdav
> or ftp the right way [tm] to work with vCards and vCal/iCal files.
> 
> The other problem is the missing ldap schema. The kdepim guys have developed
> a flexible addressbook library (libkabc) that supports all informations
> of a vCard. I'd like to see a ldap schema that also supports all informations
> of a vCard, so libkabc can use a ldap server without loosing informations.
> 
> The following suggestion isn't in a proper format, but it covers all vCard
> entities:
> 
> objectclass vCard
>   requires
>     objectClass
>     uid
>     cn
>   allows
>     givenName
>     additionalName
>     familyName
>     displayName
>     namePrefix
>     nameSuffix
>     nickName
>     birthday            // iso date format
>     mailer
>     title
>     role
>     organization
>     note
>     productId
>     sortString
>     url
>     revision            // iso date format
>     timeZone            // offset in minutes relative to UTC
>     geoPosition         // string in "(x:y)" format, x = latitude, y = langitude
>     secrecy
>     logo
>     photo
>     sound
>     agent
>     mail
>     mailalias
>     category
>     custom              // string in "app;name;value" format
> 
> objectclass vCardPhoneNumber
>   requires
>     objectClass
>     uid
>   allows
>     number
>     type               // string: the types defined in RFC2426
> 
> objectclass vCardAddresses
>   requires
>     objectClass
>     uid
>   allows
>     type               // string: the types defined in RFC2426
>     postOfficeBox
>     extended
>     street
>     locality
>     region
>     postalCode
>     country
>     label
> 
> A sample ldapsearch output would look like the following:
> 
> vCard=<uid>, $basedn
> uid=<uid>
> cn=Test Person
> givenName=Test
> additionalName=Willi
> familyName=Person
> namePrefix=Sir
> nameSuffix=Jr.
> displayName=Person, Test
> nickName=testi
> birthday=2002-09-22T17:01:45Z
> timeZone=123
> geoPosition=(123.44:-118.23)
> secrecy=PRIVATE
> logo=http://www.testhost.org/mypic.png
> photo=<base64 encoded stuff>
> mail=contact@testhost.org
> mailalias=foo@testhost.org
> mailalias=bar@testhost.org
> category=Friends
> category=Linux-User-Group
> custom=KADDRESSBOOK;X-Anniversary;2002-08-11
> custom=KADDRESSBOOK;X-Department;foobar Station
> 
> vCardPhoneNumber=123321,vCard=Sir Test Willi Person Jr., $basedn
> uid=23eRRt2
> type=Home
> type=Pref
> 
> vCardPhoneNumber=<phone-uid>,vCard=<uid>, $basedn
> uid=<phone-uid>
> number=127536453
> type=Work
> type=Fax
> 
> vCardAddressee=<address-uid>,vCard=<uid>, $basedn
> uid=<address-uid>
> type=Work
> street=TestStreet
> location=TestLocation
> region=TestResgion
> country=TestCountry
> 
> <uid>, <address-uid> and <phone-uid> are unique identifiers that consist
> of a random string with a length of 9 characters.
> (e.g. that is returned by KApplication::randomString())
> 
> That is only a suggestion, but such a schema is easy extensible and doesn't
> bound addresses or phonenumbers to a special number.
> 
> Ciao,
> Tobias
> --
> In a world without walls and fences who
> needs Windows and Gates???
> _______________________________________________
> Kroupware mailing list
> Kroupware@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kroupware

-- 

Miles Lott
http://milosch.net