Re: Proposed Charter Changes

Hi,

Apparently my emails got stuck in the Outbox for some reason but here are
a few comments on the draft charter that we feel are important
for us to share on the list (sorry for the length of the email)

1) Low level vs fine-granular wordsmithing:
For us, the term Œlow-levelı have had a specific meaning since the early
days of WebRTC and the term has been used in other contexts where APIıs
for RTC on the server side. The key thing for us to capture is the ability
for developers to explore and innovate on the control of media, transport
and connection establishment processes.

 In this we include not only the
methods of the API but also working on the semantics and syntax of the
description of the underlying browser/protocol stack capabilities.



Does Justins proposal reflect this? Looking at it, the approach for how to
solve it is good but we have the following comments:


Direct control: The new APIs are intended to provide direct control over
the details of real-time communication, where the application can directly
specify how information should be transmitted, without any built-in
negotiation semantics. 

GE: This makes it clear that O/A is not included in the exposed
capabilities but I am not sure what ³where the application can directly
specify how information should be transmitted² adds/means? Drop unless
there is a meaning behind this Iıve missed?


Backwards-compatibility: The new APIs will extend the WebRTC 1.0 APIs,
rather than replace them.

GE: Here I have a problem: Some of the issues with SDP relates to the
semantics of the attributes and parameters. b=As is one example, requires
replacement, not extension (sorry if not having english as much first
language make me read this wrong). For the sake to the Web Platform
evolution, improving that part of the API description of browser media and
networking capabilities to improve interoperability as well as providing
for more efficient fine-granular control/usage of device and network
capabilities. The WG should not be bound to keep mistakes, omissions
compromises from legacy systems and technologies if these have a negative
impact on the Web Platform security, interoperability and performance.




2) Plans for beyond the low-level API
:
The proposed charter is pretty silent on what else beyond the ³low-level
API² stuff. In DOMıs proposal, there was mentioned a re-charter. This
ensured a possibility for the WG/community to have such a discussion, thus
avoiding adding ³beyond² functions already now.

But as it stands now,
without the re-chartering being there, it is unclear to me what the
consensus is on how we handle this? Not sure what I think about that
yet.

 For this and for other reasons we would share to share our ideas on
how the WebRTC could evolve beyond the work on a ³low-level² API. This was
mentioned during the phone conference last week but since so much focus
has been on the ³low-level API², weıre concerned that this is lost a bit.



Our list of items for discussion is (which we of course are ready to
describe and discuss):

Security:
* Close harmonization rest of WebAppSec (and others) about Web platform
security evolution (see also below).
* General User Security and Privacy improvements.
* Delegation (Web app from one origin, part of find and connect, TURN,
conference servers from another provider (and origin)
  for verticals like Financial, E-health and Manufacturing.

And API surfaces for RTCWeb stack evolution we anticipate in at least the
following areas:
* More on ICE and Mobility.
* More multi-party.
* More multi-path.
* Data channel.
* PTT.

With that saidŠ

 We think the proposed charter is weak on work and
deliverables for security aspects, especially concerning the need to
coordinate with WebAppSec WG (non-normative) work. There are several key
developments there for secure confinement of JavaScript and the assumed
security model for the JS will have an impact on what and how browser and
networking capabilities are exposed. Direct coordination with these WG
(and others concerned with Privacy) should be pursued more actively. The
IETF RTCWeb WG has done a stellar job in this area, but we think the
evolution of the WebRTC in the Web Platform would benefit from helping out
in coordinating with other W3C WGıs work.



To conclude: the recent draft charters that have been sent to this list
are reasonable, but we want to make sure that other items (such as the
ones outlined above) than a low level networking API are in scope beyond
WebRTC 1.0, or that a re-chartering (as in Dom's draft ) exercise is
mentioned in
the Charter.

Many Regards
Göran AP (4Ericsson)



-----Original Message-----
From: Justin Uberti <juberti@google.com>
Date: Monday 4 May 2015 00:27
To: Erik Lagerway <erik@hookflash.com>
Cc: Cullen Jennings <fluffy@iii.ca>, Eric Rescorla <ekr@rtfm.com>, Bernard
Aboba <Bernard.Aboba@microsoft.com>, "Michael Champion (MS OPEN TECH)"
<Michael.Champion@microsoft.com>, W3C WEBRTC <public-webrtc@w3.org>
Subject: Re: Proposed Charter Changes
Resent-From: W3C WEBRTC <public-webrtc@w3.org>
Resent-Date: Monday 4 May 2015 00:28

>OK, I have tweaked Erik's proposed text to try to make it clear what the
>purpose of the new APIs are, by adding a new bullet called "Direct
>control". 
>
>
>I also performed a few other wordsmithings. Hopefully those in favor of
>Erik's proposal will also like this version.
>
>
>Diff from Erik's proposal:
>https://github.com/fluffy/webrtc-charter/compare/alt...juberti:alt
>
>
>
>Full proposal:
>https://github.com/juberti/webrtc-charter/blob/alt/proposed-charter.txt
>
>
>
>
>On Thu, Apr 30, 2015 at 2:39 PM, Justin Uberti
><juberti@google.com> wrote:
>
>I agree that NG doesn't really explain what its purpose is, and "object"
>is similarly vague.
>
>
>I think it needs the exact goal of this effort needs to be made explicit.
>I am not wedded to the term "low-level", but somehow the relationship
>between 1.0 and the new API needs to be described, as well as how the new
>API differs from the existing API.
> And to be clear, "does not use SDP" is not an adequate description; SDP
>does something, so are we inventing an alternative, or specifically
>leaving that functionality to applications (and thereby moving down a
>layer in the stack?)
>
>
>I will take a shot at coming up with text for this.
>
>
>On Thu, Apr 30, 2015 at 1:55 PM, Erik Lagerway
><erik@hookflash.com> wrote:
>
>The bulk of the changes are as follows, template from Dom, some from Ekr,
>some from Tim, some from
>me + removed the Liaison requirement.
>
>
>As the name implies, WebRTC 1.0: Real-time Communication Between Browsers
>is to be considered as a first version of APIs for real-time
>communication. The working group will, once WebRTC 1.0: Real-time
>Communication Between Browsers reaches Candidate Recommendation,
> consider working on a new set of object-oriented APIs for real-time
>communication to produce an object-oriented specification to follow 1.0.
>The activities in the ORTC (Object Real-time Communications) Community
>Group indicate that there is interest
> in a new set of APIs. As part of this consideration, the group will
>reevaluate its deliverables and milestones, and may reconsider its scope.
>
>
>In developing an Object API, the WG will adhere to the following
>principles.
>
>- Backwards-compatibility: applications which run in WebRTC 1.0 will
>continue to function with the Object API.
>
>- Standalone operation: The new Object APIs will be sufficiently complete
>as to prevent the need for the programmer to switch between
>object-orientated and 1.0 SDP styles in order to complete common tasks.
>- Feature independence: New features may be introduced in the
>object-oriented API that are not accessible in the documented
>1.0 API or that are only added to the 1.0 SDP API in future versions.
>
>
>The WG will make efforts to align on API methodologies and nomenclature
>with the ORCT CG when contemplating design of similar APIs in the WG.
>This may include scheduled design meetings with relevant WG and CG
>stakeholders to foster further convergence
> of the APIs.
>
>
>---
>
>
>Your comments around "Object" are noted, also heard that "low-level" and
>"NG" are not working for some as well, so not sure what to do there.
>
>
>
>
>
>
>/Erik
>
>
>
>
>On Thu, Apr 30, 2015 at 11:21 AM, Justin Uberti
><juberti@google.com> wrote:
>
>Can you put up a link to a github diff? It's hard to tell which parts are
>new here.
>
>
>I am not a fan of the "Object" / "1.0 SDP" terminology. Most of the
>objects already exist (or will exist) in 1.0, so calling the NG thing
>"Object" seems inaccurate at best.
>
>
>On Thu, Apr 30, 2015 at 9:59 AM, Cullen Jennings
><fluffy@iii.ca> wrote:
>
>
>I look forward to seeing the discussion on the Hookflash proposal and I
>need to think about about it more but my first reaction is that looks
>like something that I could live with and might be OK to most the WG.
>
>
>> On Apr 30, 2015, at 10:02 AM, Erik Lagerway <erik@hookflash.com> wrote:
>>
>> Based on concerns raised and after speaking to several WG and CG
>>participants, I am proposing the following changes:
>>
>> - removed liaison requirement
>> - added some copy around getting the groups working together
>> - changed "low-level" to Object
>> - changed "high-level" to 1.0 SDP
>>
>> I believe this addresses most of the concerns and feels like a common
>>ground we can start from, the proposal in its entirety is attached.
>>
>> Cheers,
>> Erik
>>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Received on Tuesday, 5 May 2015 16:01:45 UTC