RE: First agenda proposal webrtc telco

Hi Ekr,

In terms of procedure, I proposed to use Bugzilla to track such issues a while ago [1]. 
I think the mailing list is more suitable for discussing new feature proposals, while it is difficult to track such bugs in the spec or proposals.
With chairs' ability to control the bugs, it would be easy to follow an agenda to "Make a decision on X" in telcos as suggested by Jim [2].


[1] http://lists.w3.org/Archives/Public/public-webrtc/2012Jun/0231.html
[2] http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0181.html


-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: Monday, August 27, 2012 10:34 AM
To: Stefan Hakansson LK
Cc: public-webrtc@w3.org
Subject: Re: First agenda proposal webrtc telco

On Sun, Aug 26, 2012 at 11:30 AM, Stefan Hakansson LK
<stefan.lk.hakansson@ericsson.com> wrote:

> Perhaps we should change this; instead have more frequent telcos with fewer
> topic which we cover in depth. I would certainly be open for that if the WG
> (and my co-chair) thinks it is a good idea. And it would be natural to focus
> on covering the issues (in priority order) that block implementation in
> those meetings.

For my money, the best use of telcos is to resolve issues which aren't getting
resolved on the list.

My priorities may not match anyone else's but here are the things
that I think are high priority (as in they are questions that are already
holding up implementation):

- A complete description of error handling. I.e., which functions throw
exceptions, which have error callbacks. Do the functions which have
error callbacks ever throw exceptions? What is the state of affairs
after an error has occurred? Full disclosure: my position is that
any given API call should have exactly one error reporting mechanism.

- What order can/must API calls be made? E.g., can you call createAnswer()
before you call setRemote()?

- The ICE state machine, as indicated by Cullen.

-Do we need API control for trickle ICE (see my comments on the RTW mailing
list for some indications of why we might need it.)

- A whole bunch of small things in the API don't make much sense. E.g.,
the closing state I raised the other day, why you have both setRemote(OFFER)
and an offer parameter to createAnswer(), etc. We need some procedure
for closing on these inconsistencies faster.

-Ekr


-

Received on Monday, 27 August 2012 15:10:32 UTC