[contacts] Removal of serviceId from API

I'd like to request that we drop the serviceId attribute from the Contacts
API specification. Following is a description of why this is important, if
not essential for users and their data.

As it is currently provided, the serviceId attribute cannot reasonably
identify a contact record that has been sourced from a plurality of address
book sources. For example, if a contact record is the result of combining
data from a user's device-based address book and Facebook/LinkedIn/Plaxo,
the serviceId is entirely incapable of reasonably expressing the source of
this data in the serviceId field.

Removing this attribute removes the ability for web apps to change the
storage location of a particular contact record. For example, an
operator-driven web application may attempt to move all contact objects from
cloud/networked sources to the device-based address book - possibly based on
some (opaque?) policy rules. To do this the web application would need to
identify which records are not currently stored in the device, and then edit
them appropriately. Equally, a non-operator-driven web application may
attempt to move all contact objects stored in the device to the cloud in the
same manner. Importing and exporting between address books should not be an
intended use case of the Contacts API exposed to web applications. Importing
and exporting between address books should be left to other interfaces at an
implementation's discretion. Removing the serviceId attribute is the best
way to ensure that the current back-and-forth 'who owns the data' battle
doesn't spread to the web platform itself while still letting
implementations themselves decide the most appropriate data stores to use.

In cases where an implementation is required to maintain sync with an actual
data source, this should be accomplished via an implementation's
configuration panel. The implementation itself may maintain the actual data
source for individual ContactProperties as required, and sync as appropriate
(e.g. [1]). When properties are changed or added, the implementation should
sync with the necessary services as appropriate and based on
the capabilities of specific data sources to store any ContactProperties
being set. This back-end interaction is entirely obfuscated from web apps.

Notably, serviceId is the only non Portable Contacts property included in
the entire specification. Removing this attribute makes the W3C Contact
schema a direct 1:1 mapping of the Portable Contacts schema.

Please let me know your thoughts. Incidentally, for an example
implementation of this proposal please see the excellent work of Mozilla [1]
[2] [3].

This discussion relates directly to ISSUE-43.

regards, Richard

[1] http://www.open-mike.org/entry/contacts-in-the-browser-0.2(source-attributed
data as it is stored in the Mozilla Contacts
implementation - with links maintained to each address book provider as
appropriate)

[2] http://mozillalabs.com/files/2010/03/servicesView.png (Mozilla Contacts
import functionality screenshot for merging data from a plurality of
sources)

[3] http://mozillalabs.com/files/2010/03/contactView.png (Contact data as it
is exposed to web apps by the Mozilla Contacts API (notably, minus
'serviceId' location))