Re: [admin] Relationship of DAP and SysApps deliverables

Hi. Frederick.

2013/2/20 <Frederick.Hirsch@nokia.com>

>    > 2. Network Interface API****
>  >****
>  > SysApps Phase 2 deliverable, may build on DAP deliverable****
>  >****
>  > DAP: Network Information API, under current development,****
>  > https://dvcs.w3.org/hg/dap/raw-file/default/network-api/Overview.html**
> **
>  ** **
>  Sys Apps WG charter has below description for Network Interface API.
> This description already considered Network Interface API in DAP WG. So Sys
> Apps WG probably should change the name of the spec for removing confusion,
> but content of the spec would not be overlapped with Network Interface API
> of DAP WG.****
>  ** **
>  An API to manipulate network interfaces (mobile, WiFi, etc.), such as
> listing available networks, current strength, etc., as well as configuring
> and enabling them. It may build atop the simpler network information API
> that Device APIs is working on. Potential uses include offloading
> connections from mobile networks to WiFi, enabling high priority mobile
> data connections and control of other network features.
>
>
>
>  Perhaps SysApps API should be called  "Network Interface Management API" ?
>

Yes. That could be one of good option!

Best regards,
Wonsuk.



>
>  regards, Frederick
>
>  Frederick Hirsch
> Nokia
>
>
>
>  On Feb 14, 2013, at 10:40 AM, ext Wonsuk Lee wrote:
>
>   Hi. Frederick.****
>  Thanks for great summary!****
>  ** **
>  ** **
>  > -----Original Message-----****
>  > From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]***
> *
>  > Sent: Thursday, February 07, 2013 11:58 PM****
>  > To: public-device-apis@w3.org****
>  > Cc: Frederick.Hirsch@nokia.com; wonsuk11.lee@samsung.com;****
>  > w3c@adambarth.com; dsr@w3.org; dom@w3.org****
>  > Subject: [admin] Relationship of DAP and SysApps deliverables****
>  >****
>  > [Sending to DAP mail list and chairs/team, as I'm not a member of****
>  > SysApps]****
>  >****
>  > There is some overlap of the Device APIs WG  (DAP) [1]  and System****
>  > Applications WG (SysApps) [2] deliverables which may require some****
>  > coordination.****
>  >****
>  > Specifically, both DAP and SysApps have the following work items****
>  > (using SysApps terminology)****
>  >****
>  > 1. Contacts****
>  >****
>  > SysApps Phase 1 deliverable, (editors draft****
>  > http://sysapps.github.com/sysapps/proposals/Contacts/Contacts.html )***
> *
>  >****
>  > DAP : "Contacts API",****
>  > http://www.w3.org/TR/2011/WD-contacts-api-20110616/****
>  > and "Pick Contacts Intent" ,****
>  > http://www.w3.org/TR/2012/WD-contacts-api-****
>  > 20120712/****
>  ** **
>  For Contacts, in my understanding, DAP is trying to develop the contacts
> spec based on Web Intents (instead of Contact APIs) because of privacy and
> security issue. So I would like to propose to separate the R&R of DAP WG
> and Sys Apps WG as Sys Apps WG has a role for contacts APIs and DAP WG has
> a role for contact spec based on Web Intents(or Web Activity).****
>  ** **
>  ** **
>  > 2. Network Interface API****
>  >****
>  > SysApps Phase 2 deliverable, may build on DAP deliverable****
>  >****
>  > DAP: Network Information API, under current development,****
>  > https://dvcs.w3.org/hg/dap/raw-file/default/network-api/Overview.html**
> **
>  ** **
>  Sys Apps WG charter has below description for Network Interface API.
> This description already considered Network Interface API in DAP WG. So Sys
> Apps WG probably should change the name of the spec for removing confusion,
> but content of the spec would not be overlapped with Network Interface API
> of DAP WG.****
>  ** **
>  An API to manipulate network interfaces (mobile, WiFi, etc.), such as
> listing available networks, current strength, etc., as well as configuring
> and enabling them. It may build atop the simpler network information API
> that Device APIs is working on. Potential uses include offloading
> connections from mobile networks to WiFi, enabling high priority mobile
> data connections and control of other network features.****
>  ** **
>  > -----****
>  >****
>  > DAP also has items that have been 'shelved' [3] which means DAP****
>  > currently has old drafts that are no longer being progressed, but****
>  > which might be picked up again****
>  >****
>  > 3. Messaging API****
>  >****
>  > SysApps Phase 1 deliverable (editors draft****
>  > http://sysapps.github.com/sysapps/proposals/Messaging/Messaging.html )*
> ***
>  >****
>  > DAP - currently "shelved"  , http://dev.w3.org/2009/dap/messaging/****
>  ** **
>  I am not sure but I think this might has security and privacy issues.
> For example, crazy web app could send an SMS/MMS/email to somewhere else
> without user permission. So I think Sys Apps WG might be better location
> for making this spec. What do you think?****
>  ** **
>  ** **
>  > 4. Calendar****
>  >****
>  > SysApps Phase 2 deliverable****
>  >****
>  > DAP - currently "shelved", http://dev.w3.org/2009/dap/calendar/****
>  >** **
>  > 5. Device Capabilities****
>  >****
>  > SysApps Phase 2 deliverable****
>  >****
>  > DAP "System Information API" - shelved,****
>  > http://dev.w3.org/2009/dap/system-****
>  > info/****
>  >** **
>  > -----****
>  >****
>  > In addition, in passing I note the following might have some relation**
> **
>  > to Web Crypto****
>  >****
>  > 6. Secure Elements API****
>  >****
>  > SysApps Phase 2 deliverable.  No corresponding DAP deliverable, but****
>  > how does this relate  to the Web Crypto WG [4] deliverables?****
>  ** **
>  Web Cryptography API from Web Crypto WG is to define a javascript API
> for performing basic cryptographic operations in web applications, such as
> hashing, signature generation and verification, and encryption and
> decryption.****
>  But according to Gemalto SecureElement API proposal, this spec is to
> define a javascript API for allowing the communication between web
> application and a smart card or other secure element by using the
> Application Protocol Data Units (APDUs) So these would have a relationship
> but goal and use cases are different.****
>  ** **
>  ****
>  > -----****
>  > Conclusion****
>  >****
>  > I think it would be helpful to share use cases and requirements and****
>  > also consider the implications of overlap work items.****
>  ** **
>  I agreed for Calendar, Device Capabilities.****
>  ** **
>  >****
>  > In particular, regarding Contacts, we may want to****
>  >****
>  > (a) make sure that the data formats and meaning are consistent (for****
>  > interoperability)****
>  ** **
>  I agreed.****
>  ** **
>  > (b)  ask whether similar APIs across two groups should share a common**
> **
>  > API style  and practices [5] and maybe even details apart from****
>  > optional parameters or intentionally be different (whether it is****
>  > better to enable commonality or make clear distinctions)****
>  ** **
>  Generally I agreed. But there are many descriptions in [5]. So it would
> be required to review by Sys Apps WG.****
>  ** **
>  ** **
>  Best regards,****
>  Wonsuk.****
>  ** **
>  > Thoughts? I hope this is helpful.****
>  >****
>  > regards, Frederick****
>  >****
>  > Frederick Hirsch, Nokia****
>  > Chair, W3C DAP Working Group****
>  >****
>  > [1] http://www.w3.org/2009/dap/****
>  >****
>  > [2] http://www.w3.org/2012/sysapps/****
>  >****
>  > [3] http://lists.w3.org/Archives/Public/public-device-****
>  > apis/2011Nov/0026.html****
>  >****
>  > [4] http://www.w3.org/2012/webcrypto/****
>  >****
>  > [5] API checklist,  http://www.w3.org/2009/dap/wiki/ApiCheckList****
>  >****
>  > Web API Design Cookbook,****
>  > http://darobin.github.com/api-design-cookbook/****
>  >****
>  > For tracker, complete ACTION-612****
>  ** **
>  ** **
>
>
>


-- 

=========================================
이 원 석 (Wonsuk, Lee) / Principal Engineer, Ph.D
SAMSUNG ELECTRONICS Co., LTD. (三星電子)
Mobile: +82-10-5800-3997
E-mail: wonsuk11.lee@samsung.com, wonsuk73@gmail.com
http://www.wonsuk73.com/, twitter: @wonsuk73
-----------------------------------------
Inspire the World, Create the Future !!!
=========================================