RE: [contacts] Removal of serviceId from API

Hi Dom,

-----Original Message-----
From: Dominique Hazael-Massieux [] 
Sent: Wednesday, June 23, 2010 11:32 AM
To: Suresh Chitturi
Cc: Rich Tibbett;
Subject: RE: [contacts] Removal of serviceId from API

Hi Suresh,

Le mercredi 23 juin 2010 à 11:22 -0500, Suresh Chitturi a écrit :
> You make some good points, but I'm still not convinced that we should
> remove it from the spec. It has to exist at some place in the spec to
> link your web app to defined service-based contacts list.
> As a user, there are use cases that show that user would like to
> view/search for just the device contacts, or xxx service contacts. So
> the source is important to capture in the API. This is available in
> the implementations today so why not expose it to the developer.

I think there are two points to consider:
* whether serviceId is the right way to make that information available
- I'm fairly sure it isn't, and that we would need an AddressBook
interface to do that sufficiently well

Suresh>> I think the Contacts interface in the spec acts as the 'AddressBook' interface, if I'm not wrong.

* whether that feature needs to be part in the v1 of the spec - I
personally think that while the use cases that require source-awareness
might be interesting, it's more important to finish a first version of
the spec that is already useful without that source-awareness than
getting bogged into the potentially difficult details of that aspect;
that's obviously a judgment call

Suresh>> Actually, I don't think it is a complicated piece to specify, we already have it in the spec, and we just need to tighten it up as with everything else that is in the draft.



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 Wednesday, 23 June 2010 17:36:20 UTC