Re: [W3C TCP and UDP Socket API]: Status and home for this specification

On 2015-04-07 07:07, Nilsson, Claes1 wrote:
> Hi Frederick,
>
> The implementations I am aware of are:
>   
> * Mozilla FFOS: There is an ongoing implementation of the UDP API. See https://bugzilla.mozilla.org/show_bug.cgi?id=745283
> * Crosswalk: An experimental implementation of the old, non-stream-based version. See https://crosswalk-project.org/documentation/apis/web_apis.html

If it had 2 fairly significant implementations, that can be an argument 
for keeping it in a WG rather than moving it to a Community Group (where 
it doesn't need 2) (I think that may have been what the question was about.)

Crosswalk has an experimental implementation of a previous version that 
was fairly different.   We (Intel) have quit the SysApps WG and think it 
should have closed when the Charter expired.
https://crosswalk-project.org/documentation/apis/web_apis.html

Mozilla looks like they have their own, different API
https://developer.mozilla.org/en-US/docs/Web/API/TCPSocket



>
> There is no public web page with this information.
>
> BR
>    Claes
>
>
>
> Claes Nilsson
> Master Engineer - Web Research
> Advanced Application Lab, Technology
>
> Sony Mobile Communications
> Tel: +46 70 55 66 878
> claes1.nilsson@sonymobile.com
>
> sonymobile.com
>
>
>
>> -----Original Message-----
>> From: Frederick Hirsch [mailto:w3c@fjhirsch.com]
>> Sent: den 7 april 2015 13:53
>> To: Nilsson, Claes1
>> Cc: public-sysapps@w3.org; public-webapps; Device APIs Working Group;
>> Domenic Denicola; slightlyoff@chromium.org; yasskin@gmail.com
>> Subject: Re: [W3C TCP and UDP Socket API]: Status and home for this
>> specification
>>
>>> Lastly, if there is a decision to continue to work on this API I can
>> remain as main editor. However, I can currently not commit to more
>> extensive tasks such as implementation and test cases.
>>
>> Claes
>>
>> Do you have information on W3C members committed to implementation &
>> test cases going forward? This might be useful before considering venue
>> for the work and detailed issues. (Is there a public web page with
>> information on current implementations?)
>>
>> thanks
>>
>> regards, Frederick
>>
>> Frederick Hirsch
>>
>> www.fjhirsch.com
>> @fjhirsch
>>
>>
>>
>>> On Apr 1, 2015, at 5:22 AM, Nilsson, Claes1
>> <Claes1.Nilsson@sonymobile.com> wrote:
>>> Hi all,
>>>
>>> Related to the recent mail thread about the SysApps WG and its
>> deliverables I would like to make a report of the status of the TCP and
>> UDP Socket API, http://www.w3.org/2012/sysapps/tcp-udp-sockets/.
>>> Note that this specification is still being worked on. Latest merged
>> PR was March 30. I think it is time for a new Public Working Draft.
>>> This API is used to send and receive data over the network using TCP
>> or UDP.
>>> Examples of use cases for the API are:
>>>  • An email client which communicates with SMTP, POP3 and
>> IMAP servers
>>>  • An irc client which communicates with irc servers
>>>  • Implementing an ssh app
>>>  • Communicating with existing consumer hardware, like
>> internet connected TVs
>>>  • Game servers
>>>  • Peer-to-peer applications
>>>  • Local network multicast service discovery, e.g. UPnP/SSDP
>> and mDNS
>>> The TCP and UDP Socket API is a phase 1 deliverable of the SysApps WG.
>> SysApps was originally chartered to provide a runtime and security
>> model so that it would be possible to open up sensitive APIs to SysApps
>> enabled runtimes. Accordingly, it was assumed that the TCP and UDP
>> Socket API would be exposed to such a “trusted runtime”. Looking at
>> existing TCP and UDP Socket APIs they are implemented in proprietary
>> web runtimes, FFOS and Chrome, which provide a security model for
>> installed packaged web runtimes.
>>> Today we can conclude that it has not been possible to standardize a
>> runtime and security model in SysApps. However, there still seems to be
>> an interest in the TCP and UDP Socket API, at least from individuals at
>> Google and Mozilla. For example, there has been extensive work,
>> supported by Google, to adapt this API to the Streams API specification,
>> https://streams.spec.whatwg.org/.
>>> To meet the issue that we don’t have a standardized secure “web
>> system applications” runtime and that the current open web browser
>> sandbox is not secure enough for this kind of API (but the security
>> features are evolving through the Web Application Security Working
>> Group) I recently added “permission methods”, partly inspired by the
>> W3C Push API. A webapp could for example request permission to create a
>> TCP connection to a certain host. The ambition is to isolate the
>> permission system from the socket interfaces specifications and the
>> manner in which permission to use this API is given differs depending
>> on the type of web runtime the API is implemented in. For example, a
>> web runtime for secure installed web applications may be able to open
>> up this API so that no explicit user content is needed, while an
>> implementation in a web browser may use a combination of web security
>> mechanisms, such as secure transport (https:), content security
>> policies (CSP), signed manifest, certificate pinning, and user consent
>> to open up the API.
>>> If SysApps WG is closed and the scope of W3C is limited to APIs that
>> could be exposed the “normal browser context” (which is evolving, once
>> again referring to Web Apps Sec WG) a new home for this API could be
>> the Device API WG. A Community Group, similar to what we have for Web
>> Bluetooth and NFC, would also be a possibility.
>>> WDYT?
>>>
>>> Lastly, if there is a decision to continue to work on this API I can
>> remain as main editor. However, I can currently not commit to more
>> extensive tasks such as implementation and test cases.
>>> Best regards
>>>    Claes
>>>
>>>
>>> Claes Nilsson
>>> Master Engineer - Web Research
>>> Advanced Application Lab, Technology
>>>
>>> Sony Mobile Communications
>>> Tel: +46 70 55 66 878
>>> claes1.nilsson@sonymobile.com
>>>
>>> sonymobile.com
>>>
>>> <image003.png>

Received on Tuesday, 7 April 2015 23:53:09 UTC