Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

[Justin Uberti <[e-mail]>]

On Mon, Feb 3, 2014 at 1:10 PM, Adam Roach <[e-mail]> wrote:

>  On 2/3/14 15:03, Justin Uberti wrote:
>
>
> On Mon, Feb 3, 2014 at 12:42 PM, Adam Roach <[e-mail]> wrote:
>
>> On 2/3/14 14:25, Justin Uberti wrote:
>>
>>> It's not clear to me that adding a new attribute would solve any problem
>>> that appid doesn't solve; you still need to deal with the "other end not
>>> using it" issue.
>>>
>>
>>  Regardless of whether you think there's a problem in the legacy interop
>> case, the big benefit here is that an explicit indicator by definition
>> makes the operation explicit, and that in-and-of-itself is a good thing.
>>
>> The core issue is that you're trying to make the operation implicit; your
>> proposal edges awfully close to the DWIM model of design, which we know
>> causes problems when we try to add further extensions.
>
>
>  Good point, but since we are still defining exactly what appId does, I
> think we have the opportunity to make it explicit.
>
>
> I think I agree, but this isn't congruent with the proposal you made
> before. Omitting app-id as a means of rejecting a stream is an implicit
> operation, regardless of how well it's documented.
>
> If you want to have something like "a=recv-appId:reject", that would be
> suitably explicit, but I really have a hard time imagining how something
> like that would be preferable to just having a new attribute.
>

I was thinking a=recv-appId:0, which is both explicit, and has parallels
with the zero port form of rejecting a m= line.