Excellent, thanks Mike.

I'll put the full iOS optimised setup on the wiki for if anyone wants 
the whole deal.

Simon.

- Enabled the POOMCONTACTS2 schema in Horde_ActiveSync regardless of version
- Applied your changes to Turba_Driver:: to translate <-> activesync messages.
- Added your changes to attributes.php
- Added *some* of the new fields to the default turba_objects schema 
and enabled in backends.php.

Thanks!

(please remove the old one)

My SQL Backend definition to make use of the previous changes, 
optimised for iOS.

Required turba_objects MYSQL attached

/var/www/horde4/turba/config/attributes.php patch2

(please remove the original one)

/var/www/horde4/turba/lib/Driver.php patch2

(Please remove the original one)

OK, completed.

Fully functional, apart from one oddness. First edit after creating 
each of the new mappings seemed to not go through, from either end. 
But once it had done one (pushed by a re-edit, which firstly generated 
an error about inconsistent state), then it is fine, and syncs across 
any contact without any problem.

So, I have added:

IMAddress
IMAddress2
IMAddress3
Nickname
CompanyMainPhone

For the sake of completeness, although it appears of minimal value! i 
have also added "Radio phone".

That gives me a full set of contact attributes in iOS, i.e. every 
attribute that you can add to a contact in iOS is mapped successfully 
into Turba. Turba has some additional ones that don't go to iOS (e.g. 
SMIME and PGP) but I figure that's an acceptable outcome.

For the IMAddress fields I have just generated text fields, I wasn't 
sure if they need to be anything else.

First patch is from your post below to 
/usr/share/pear/Horde/ActiveSync/Message/Contact.php, attached to this 
comment.

OK, I patched Contact.php and then added CompanyMainPhone back into 
Driver.php. Added the attribute, and added to backend.local.

Seemed to not take the first change (iOS initiated) but then made a 
change in Turba and it synced thru to iOS. Rechanged in iOS and in 
synced back to Turba.

At this stage have only had time to do the one attribute, will play 
with nickname and a couple of the other in the coming days.

Looking good... :)

Simon

Haven't forgotten about this Mike, just haven't had time! Will have a 
go over the weekend.

Will try that in next couple of days and post back with results Mike.

Cheers
Simon.

From what I understood, that schema is only available in ActiveSync 
version 12.0 and above.  They are defined in 
Horde_ActiveSync_Message_Contact.  You can try moving the definitions 
out of the conditional that tests for the AS version:

diff --git 
a/framework/ActiveSync/lib/Horde/ActiveSync/Message/Contact.php 
b/framework/ActiveSync/lib/Horde/ActiveSync/Message/Contact.php
index 303b6bf..676ba85 100644
--- a/framework/ActiveSync/lib/Horde/ActiveSync/Message/Contact.php
+++ b/framework/ActiveSync/lib/Horde/ActiveSync/Message/Contact.php
@@ -210,34 +210,31 @@ class Horde_ActiveSync_Message_Contact extends 
Horde_ActiveSync_Message_Base
              'categories' => false,
          );

-        /* Additional mappings for AS versions >= 2.5 */
-        if (isset($params['protocolversion']) && 
$params['protocolversion'] >= 2.5) {
-            $this->_mapping += array(
-                self::CUSTOMERID => array(self::KEY_ATTRIBUTE => 
'customerid'),
-                self::GOVERNMENTID => array(self::KEY_ATTRIBUTE => 
'governmentid'),
-                self::IMADDRESS => array(self::KEY_ATTRIBUTE => 'imaddress'),
-                self::IMADDRESS2 => array(self::KEY_ATTRIBUTE => 
'imaddress2'),
-                self::IMADDRESS3 => array(self::KEY_ATTRIBUTE => 
'imaddress3'),
-                self::MANAGERNAME => array(self::KEY_ATTRIBUTE => 
'managername'),
-                self::COMPANYMAINPHONE => array(self::KEY_ATTRIBUTE 
=> 'companymainphone'),
-                self::ACCOUNTNAME => array(self::KEY_ATTRIBUTE => 
'accountname'),
-                self::NICKNAME => array(self::KEY_ATTRIBUTE => 'nickname'),
-                self::MMS => array(self::KEY_ATTRIBUTE => 'mms'),
-            );
+        $this->_mapping += array(
+            self::CUSTOMERID => array(self::KEY_ATTRIBUTE => 'customerid'),
+            self::GOVERNMENTID => array(self::KEY_ATTRIBUTE => 
'governmentid'),
+            self::IMADDRESS => array(self::KEY_ATTRIBUTE => 'imaddress'),
+            self::IMADDRESS2 => array(self::KEY_ATTRIBUTE => 'imaddress2'),
+            self::IMADDRESS3 => array(self::KEY_ATTRIBUTE => 'imaddress3'),
+            self::MANAGERNAME => array(self::KEY_ATTRIBUTE => 'managername'),
+            self::COMPANYMAINPHONE => array(self::KEY_ATTRIBUTE => 
'companymainphone'),
+            self::ACCOUNTNAME => array(self::KEY_ATTRIBUTE => 'accountname'),
+            self::NICKNAME => array(self::KEY_ATTRIBUTE => 'nickname'),
+            self::MMS => array(self::KEY_ATTRIBUTE => 'mms'),
+        );

-            $this->_properties += array(
-                'customerid' => false,
-                'governmentid' => false,
-                'imaddress' => false,
-                'imaddress2' => false,
-                'imaddress3' => false,
-                'managername' => false,
-                'companymainphone' => false,
-                'accountname' => false,
-                'nickname' => false,
-                'mms' => false,
-            );
-        }
+        $this->_properties += array(
+            'customerid' => false,
+            'governmentid' => false,
+            'imaddress' => false,
+            'imaddress2' => false,
+            'imaddress3' => false,
+            'managername' => false,
+            'companymainphone' => false,
+            'accountname' => false,
+            'nickname' => false,
+            'mms' => false,
+        );


Let me know if this enables these fields for you on your iOS device, 
then I'll test to be sure it doesn't break anything else for other 
devices that do not support them.

So....

My thoughts were that the first two patches could probably be included 
in release, as they add generic ActiveSync capability within the 
framework of existing schema, etc, and do not change any existing 
definitions.

The extra SQL fields could probably also be included in release - no 
harm if they are not used.

The backends.local source definition and the couple of 
attributes.local definition changes are obviously more specific to iOS 
setups. They may be better placed in a Wiki article - open to 
suggestions on that one.

Simon.

Now to my more specific changes that are targeted specifically at 
setting up an aligned Turba / iOS address book rather than more 
generic Driver capability...

I have attached a backend definition that maps what can be mapped 
using the patches provided in previous comments, and which, along with 
the below attributes.local.php additions, optimises some labels etc to 
best match the iOS devices and labels:

attributes.local.php:

<?php
/* Mapped to activeSync Email3Address */
$attributes['workEmail'] = array(
     'label' => _("Email"),
     'type' => 'email',
     'required' => false,
     'params' => array('allow_multi' => false, 'strip_domain' => 
false, 'link_compose' => true)
);
/* Mapped to activeSync Email2Address */
$attributes['homeEmail'] = array(
     'label' => _("Email"),
     'type' => 'email',
     'required' => false,
     'params' => array('allow_multi' => false, 'strip_domain' => 
false, 'link_compose' => true)
);
/* iOS first "Work" number */
$attributes['workPhone'] = array(
     'label' => _("Work Direct"),
     'type' => 'phone',
     'required' => false
);

It also builds on some existing ActiveSync driver definitions with 
definitions already in attributes.php for which SQL fields need to be 
added:

object_email2         varchar(255)
object_email3         varchar(255)
object_anniv         varchar(10)
object_department         varchar(255)
object_spouse         varchar(255) (note that while iOS advertises this one 
the field is not visible in the Contacts app).

Atributes.php patch

Driver.php patch.

As per discussions with Mike on the mailing lists...

Turba 'out of the box' misses several key Activesync attributes to 
sync well with iOS devices.

I have patched turba/lib/Driver.php to be able to pass through more of 
the native fields, both Turba->AS, and AS->Turba.

The patch adds support for the following Activesync capabilities to 
the Turba driver, mapping to the indicated new attributes:

otherstreet => otherStreet
othercity => otherCity
otherstate => otherProvince
otherpostalcode => otherPostalCode
othercountry => otherCountry
home2phonenumber => homePhone2
business2phonenumber => workPhone2
homefaxnumber => homeFax
carphonenumber => carPhone
assistnamephonenumber => assistPhone

I have also added the relevant attributes to attributes.php. I will 
attach that patch next.
For the sake of completeness I have also defined otherPOBox in 
attributes.php, although iOS does not use it, and my address book 
definition in backends.local.php does not either.
These components shouldn't break anything existing I don't believe, as 
they only add capability, they don't change any existing capability.
I have modified further with some Label changes etc, but they are not 
included here.
I will put up my backend definition and attributes.local.php that 
align the Turba address book with iOS shortly also.

These require the addition of the following SQL fields to turba_objects:

object_otherstreet varchar(255)
object_otherpob varchar(10)
object_othercity varchar(255)
object_otherprovince varchar(255)
object_otherpostalcode varchar(10)
object_othercountry varchar(255)
object_homephone2 varchar(25)
object_workphone2 varchar(25)
object_homefax varchar(25)
object_carphone varchar(25)
object_assistphone varchar(25)

I would have added further capability, but it appears that the Horde 
Activesync library does not support the CONTACTS2 schema, so I cannot 
map the following:

IMAddress
IMAddress2
IMAddress3
ManagerName
CompanyMainPhone
NickName

Those are all advertised by iOS, but attempting to map them in 
Driver.php causes ALL contacts to disappear from the device. From my 
research they appear to be in that separate schema.
The NickName and CompanyMainPhone fields particularly would have been good...