W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2010

Re: R: Features draft - next steps

From: <Frederick.Hirsch@nokia.com>
Date: Mon, 16 Aug 2010 17:51:06 +0200
To: <marco.marengo@telecomitalia.it>
CC: <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
Message-ID: <3DDF575D-37A4-40E6-937E-BE6356623AFB@nokia.com>
Thanks Marco

comments inline

regards, Frederick

Frederick Hirsch
Nokia



On Aug 16, 2010, at 4:06 AM, ext Marengo Marco wrote:

> Hi Frederick,
> a few thoughts on the Messaging features:
> 
> 1) Subscribe to SMS message notifications
> The correct mapping of http://bondi.omtp.org/api/1.1/messaging.sms.subscribe is android.permission.RECEIVE_SMS ("Allows an application to monitor incoming SMS messages, to record or perform processing on them")

Makes sense, updated draft accordingly.

> 
> 2) Subscribe to MMS message notifications
> The correct mapping of http://bondi.omtp.org/api/1.1/messaging.sms.subscribe
> Is android.permission.RECEIVE_MMS
> 

Makes sense, updated draft with RECEIVE_SMS


> 3) Retrieve SMS / Retrieve MMS
> The current mapping looks wrong, as features like messaging.XXX.get result in BONDI in calls to APIs such Call to MessagingManager.findXXXs [1]
> 
> I'd suggest a mapping between:
> http://bondi.omtp.org/api/1.1/messaging.sms.get <-> android.permission.READ_SMS

Did this for SMS, did not see corresponding permission for android MMS.

I don't quite understand the Android security model here, maybe someone can help. I *think* RECEIVE_SMS includes READ_SMS permission by default and that READ_SMS is a narrower permission. I think MMS may only have RECEIVE_MMS and not READ_MMS  due to need to process  an attached image?



> 
> 4) Write message / Send message features
> The current list implies that DAP will specify different features for creating a { sms, binary-sms, email, mms } and for sending it. I'd keep only the permission to send a message, as it implies the permission to create one.
> Or maybe I'm just misinterpreting the android.permission.WRITE_SMS permission?

If this is one of the android and BONDI differences, we will have to decide what is appropriate for the standard. There are probably other points of comparison missing from the draft as well. 

I think this comparison helps where there is agreement, so we can have more confidence in those choices, and in highlighting where decisions are needed.


> 
> 
> Best regards,
> Marco
> 
> 
> 
> 
> [1] http://bondi.omtp.org/1.1/apis/apifeatures.html
> 
> 
> -----Messaggio originale-----
> Da: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] Per conto di Frederick.Hirsch@nokia.com
> Inviato: luned́ 9 agosto 2010 21.41
> A: Frederick.Hirsch@nokia.com
> Cc: public-device-apis@w3.org
> Oggetto: Re: Features draft - next steps
> 
> Android has a list of permissions [1].  These are strings, not URIs, but we can compare the granularity and operations included.
> 
> In some cases they may be essentially the same as the BONDI features [2], but we have to be careful since the meaning might be different even if the name appears the same.
> 
> I've updated  the Features draft to list the Android permissions that appear to correspond to the DAP APIs, and also updated the references, and coalesced a variety of similar warning notes.
> 
> I'm going to take a look at comparing the meanings of the various items.
> 
> I think we need to review/prune the list for messaging, can anyone please help with that?
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> [1] http://developer.android.com/reference/android/Manifest.permission.html
> 
> [2] http://bondi.omtp.org/1.11/apis/apifeatures.html
> 
> 
> On Aug 9, 2010, at 1:59 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote:
> 
>> At the London F2F the WG decided to work on a Features draft as a next step on Device API policies [1]. The intent is that this would be applicable to various contexts, including device APIs policy, the widget feature element, and possibly the checkPermissions proposal [2] and installable applications manifest suggestion [3] from the privacy workshop.
>> 
>> We also discussed the value of understanding approaches already in use, for example in Android [4].
>> 
>> We have a draft "Device API Features" document that includes feature URIs from the BONDI contribution to the WG. The draft is at http://dev.w3.org/2009/dap/features/ .  There are also some open actions related to this document.
>> 
>> Please share any proposals for text and content related to features on the DAP mailing list.
>> 
>> By default I'd expect we'd refine the material from the BONDI contribution to correspond to the various API drafts in progress.
>> 
>> If you are able to help please let Robin and myself know.
>> 
>> Thanks
>> 
>> regards, Frederick
>> 
>> Frederick Hirsch, Nokia
>> Co-Chair, W3C DAP Working Group
>> 
>> [1] http://www.w3.org/2010/07/14-dap-minutes.html#action13
>> 
>> [2] http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0279.html and thread,
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/att-0343/minutes-2010-06-30.html#item03
>> 
>> [3] section 5, http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-24.pdf
>> 
>> [4] http://developer.android.com/guide/topics/security/security.html
>> 
>> (For tracker, this completes ACTION-244)
>> 
> 
> 
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
> 
Received on Monday, 16 August 2010 15:52:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:12 GMT