Subject: [rtcweb] Charter reminder

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Feb 2012 13:07:21 -0800

The chairs wish to remind the working group of this aspect of the WG charter:

"This work will be done primarily by using already defined protocols
or functionalities.
If there is identification of missing protocols or functionalities,
such work can be requested
to be done in another working group with a suitable charter or by
requests for chartering it
in this WG or another WG."

Further work on signaling that does not fit within the current set of
IETF standards, such as proposed
in the ROAP and JSEP drafts, would require either rechartering this
working group, chartering a new
working group or having them adopted within a working with an
appropriate charter (most probably mmusic).

Ted Hardie for the Chairs

---

From: Tim Panton <[email-masked]>
Date: Tue, 7 Feb 2012 22:40:16 +0000

> Ted Hardie for the Chairs

Only pre-existing IETF documents acceptable here.

That being the case I think we had better take a look at rfc5456 since it
meets the bulk of the requirements expressed in the charter.

Tim.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Feb 2012 14:48:23 -0800

> Only pre-existing IETF documents acceptable here.
I think that's a little too terse a summary.  The IETF charters
working groups with a defined scope.
If a working group decides that work needs doing that doesn't fit
within that scope
the choices almost always boil down to:  increase the scope; find an
existing group
for which it is in scope and go there for that piece of work; charter
a new group with that scope.  The chairs
want to remind folks of that because work outside our currently
defined scope is being proposed.  We
are not saying "don't do the work".

Hope that clears up any confusion,

Ted

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 7 Feb 2012 16:24:24 -0700

> Hope that clears up any confusion,

+1 Ted and like to add... 

We are already have several topics in this WG where we taken some work that needed to get done, and sent it off to some more appropriate working group.

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 8 Feb 2012 05:46:20 +0000

Does the charter not include drafting a requirements document to give to W3C that might include requirements of the API? Thus any description of a signaling method that produces as its conclusion a set of API requirements should be in scope.

Matthew Kaufman

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 08 Feb 2012 01:15:35 -0500

No problem with the reminder, but I read it then that no consensus on 
JSEP vs ROAP is to be determined at the moment.  Am I right?

(I am still trying to understand where we are post interim.)

Igor

On 2/7/2012 4:07 PM, Ted Hardie wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Wed, 08 Feb 2012 11:27:21 -0500

> Ted Hardie for the Chairs

Ok.  You may be right on this (hopefully, since you're a chair). :-)

I'll go out on a rhetorical limb here...  And not I'm not an expert on 
what's in the IETF's domain or not.

Since both ROAP and JSEP do not define on-the-wire protocols, one could 
make an argument that ROAP and JSEP are both JS APIs within the charter 
of W3C, and not the IETF.

They both leverage SDP, of course, but neither specifies what goes onto 
the wire. It could all get converted to H.323, for that matter, or 
something totally different with no SDP per-se.  So to some extent 
(mostly how you resolve the local/remote SDPs) it may fall into the 
IETF; to a large extent it's either explicitly in the app's domain, or 
it's the JS API and standards for how to use it, which seems like they 
would fall into the W3C's domain.

In reality, this all straddles the divide (and is much more on the W3C 
side than if we had decided to define/select a direct on-the-wire protocol).

That said - we (IETF) can define an RFC for how to exchange SDPs and 
resolve their values, which amounts to the equivalent to JSEP, without 
defining the JS API itself in our RFC.  This implies that eventually we 
should split JSEP into an RFC for how to resolve the SDPs, and a W3C API 
we propose for doing it (i.e. Kaufman's comment).  ROAP, since it was 
based on RFC 3264, would not in my mind need a new RFC for SDP 
negotiation, just a W3C API.  For both we would probably specify which 
SDP options are allowed.

(*Please* note I don't mean this to engender a long discussion of how to 
split them or if I'm correct about the dividing line - I'm just pointing 
out we may not need to spin off as much as some might think.)  We have 
enough long discussions already.  :-(

If we need to spin something off for standardization or expand our 
charter - fine, let's do that.  Let's just be careful not to massively 
expand our schedule, as the market won't wait for us, and it's hard to 
put genies back in bottles.  (Speaking as an individual.)  Quoting Ted 
(and zillions of others): the perfect is the enemy of the good.

-- 
Randell Jesup
[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Wed, 8 Feb 2012 09:38:50 -0800

On Tue, Feb 7, 2012 at 10:15 PM, Igor Faynberg
<[email-masked]> wrote:
>
>
> No problem with the reminder, but I read it then that no consensus on JSEP
> vs ROAP is to be determined at the moment.  Am I right?
>

The consensus call is on going; this is a general reminder about the
current charter scope.

Ted

---

From: Ted Hardie <[email-masked]>
Date: Wed, 8 Feb 2012 09:56:42 -0800

Hi Randell, Matthew,

Since you both had questions on the same point, I piled the answers into
one message.

On Wed, Feb 8, 2012 at 8:27 AM, Randell Jesup <[email-masked]> wrote:

> Since both ROAP and JSEP do not define on-the-wire protocols, one could make
> an argument that ROAP and JSEP are both JS APIs within the charter of W3C,
> and not the IETF.
>
Yes.  If they specify APIs only, they are either recommendations from the IETF
to the W3C on the API or documents that might move into the W3C.  But....

> They both leverage SDP, of course,

if they require *new* work related to SDP, either in syntax or
context-specific semantics
for existing syntax, that work has to be in the IETF, and it has to
recognize the
charter scope.

The working group has previously agreed that creating something other than SDP
would be too slow, given that it would have to have at least all of
the features of
SDP that aren't multicast-specific in order to meet its interoperablity goals
(and given a history of attempts at it that do not feature a lot of success).

Without consulting the other chairs, I couldn't call consensus on
this, but at least
so far I have not heard anything that I would say challenges that
previous decision.

<personal hat>

My personal opinion is that any API that can provide a mapping to what the
equivalent SDP incantation would be is going to find the interoperability issues
much easier to tackle.  If the entire API can be mapped into existing SDP
incantations (whether offer/answer or declarative), then the work will fit
entirely within our existing charter.  That is likely the fastest way forward,
though it may still require a way to show context (offer/answer vs. declarative)
that has historical been inferred from using protocol.

An additional opinion, completely free for the asking and at no cost to you, is
that new syntax for new semantics will have a lower total cost of introduction,
compared to re-using existing syntax with context-specific semantics.  There
are certainly contrary examples, but, hey, everybody's got an opinion and that
one is mine.

</personal hat>

> <snip>

> If we need to spin something off for standardization or expand our charter -
> fine, let's do that.  Let's just be careful not to massively expand our
> schedule, as the market won't wait for us, and it's hard to put genies back
> in bottles.

I agree on both points, at least wearing my personal hat.

regards,

Ted

 (Speaking as an individual.)  Quoting Ted (and zillions of
> others): the perfect is the enemy of the good.
>
> --
> Randell Jesup
> [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 9 Feb 2012 22:40:12 +0000

> meets the bulk of the requirements expressed in the charter.

RFC 5456 is not an IETF standard, nor even an IETF document.  It was an independent submission to the RFC Editor, which is outside of the IETF.

-hadriel