RE: Contacts API: vCard vs. PoCo

Richard, all,

During this exercise, I think it is important to consider all the
sources:

- vCard (I believe vCard 4.1 is the latest version)
- PoCo
- Attributes used by existing social networks
- Attributes used by majority of current/available handsets

As mentioned during F2F, I still believe we should focus on the "core"
set or the least common denominator. Otherwise, we may need to discuss
how the testing/IOP is done when certain attributes are not supported on
a particular implementation. 

As a rule, I think the API should be influenced by the underlying
implementation and not the other way around i.e. forcing certain
implementations based on the API. Having said this I am not against
using vCard as a starting point but we need to understand all the
implications around it.

Another option would be to consider an API design that will allow access
to a basic set of attributes and would also allow "extended" attributes
that can be supported beyond what is mandated by the spec.

Regards,
Suresh

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of
richard.tibbett@orange-ftgroup.com
Sent: Tuesday, November 10, 2009 2:06 PM
To: public-device-apis@w3.org
Subject: Contacts API: vCard vs. PoCo

Hi all,

At the TPAC we agreed to implement a superset of Contact properties as
part of the Contacts API. In this discussion we agreed around
incorporating vCard [1] as the base of this Interface. This has now been
updated and is available online [2] (once again, this is an early
editor's draft so please take with two sugars).

In the mean time, the Portable Contacts API (PoCo) [3] has come to the
attention of a few members of the group as a potential contender to
vCard for the basis of the Contacts API.

Parsing both specs, I understand that vCard represents the most closely
aligned standard to traditional offline Contact databases (E.g.
Outlook). What vCard lacks is some properties that have arisen from
online social networking over the last few years since the introduction
of the vCard standard (in 1996). The Portable Contacts API aims to merge
the traditional vCard standard with the OpenSocial specifications
resulting in a hybrid API for accessing contacts data from both
traditional address books and online social networks. 

In my understanding from reading the latest PoCo API draft spec [4] I do
see breaks from the traditional vCard specification. Largely, this spec
extends the work of IETF with the work of OpenSocial although a lot of
conventions strictly defined in vCard seem to be ignored or removed from
PoCo. Having said this, tools do exist for converting vCards to PoCo and
PoCo to vCards implying that interop and any necessary conversion is
possible [5].

As PoCo represents a larger set of Contact attributes, I'd like to
propose that we make PoCo the basis of the DAP Contacts API.

On a final note, it is worth noting that both vCard and PoCo represent a
superset of both initial Contact API inputs to the DAP WG: [6] and [7].

If anyone has further thoughts or would like to initiate further
discussion please let us know.

br/ Richard



[1] http://www.ietf.org/rfc/rfc2426.txt

[2] http://dev.w3.org/2009/dap/contacts/

[3] http://portablecontacts.net

[4] http://portablecontacts.net/draft-spec.html

[5] http://www.plaxo.com/pdata/vcardTest

[6]
http://lists.w3.org/Archives/Public/public-device-apis/2009Apr/att-0001/
contacts.html

[7] http://bondi.omtp.org/1.1/CR/apis/contact.html



----------
|        |   Rich Tibbett
|        |   Orange Labs UK
| orange |   E: richard.tibbett@orange-ftgroup.com
----------   


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Tuesday, 10 November 2009 20:19:47 UTC