- From: Suresh Chitturi <schitturi@rim.com>
- Date: Tue, 10 Nov 2009 15:19:06 -0500
- To: <richard.tibbett@orange-ftgroup.com>, <public-device-apis@w3.org>
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