Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

[Harald Alvestrand <[e-mail]>]

On 10/11/2013 01:31 PM, Martin Thomson wrote:
> On 11 October 2013 04:05, Harald Alvestrand <[e-mail]> wrote:
>> This topic may have solutions that aren't being pursued in the RTCWEB WG.
>>
>> In particular:
>>
>> http://www.w3.org/TR/2013/WD-discovery-api-20130924/
>>
>> describes a proposal for how to find objects on the local net (currently:
>> announced via upnp and zeroconf), and
>>
>> http://www.w3.org/TR/netinfo-api/
>>
>> describes a proposal for getting some information about how you're connected
>> to the network.
> Those solutions may not be appropriate for use in web browsers, in
> much the same way that the "raw sockets" API is not.

That's the reason why I selected those particular ones - they are 
proposals being made for use in browsers.

They might be successful or unsuccessful, but the browsers are their target.

>
>> Getting that information may be out of scope for WEBRTC or RTCWEB.
>> Putting that information to use once we have it may be in scope.
> I find it more appropriate to say first that the problem is in scope,
> then to look for solutions that you don't have to build yourself.  It
> seems that if you want to be able to do priority marking, then a way
> of discovering what markings do what is entirely in scope.
>
> This is, of course, another case where the delineation of
> responsibilities is required.  The W3C group you chair might decide to
> use the discovery API, but there may be a need to assess the discovery
> mechanisms here.
>
> Other items on the list - a reasonable set of questions - seemed like
> even larger problems.  If we're talking about a generic way to
> advertise packet prioritization capabilities in a network, plus ways
> to manage access to those features, that's a non-trivial enterprise.

Yup. Those proposals above don't address those problems. But if they are 
able to do what they are designed to do, following their lead may be 
more doable than striking out in a completely new direction.

(The netinfo API seems a bit moribund, btw. If anyone knows why, it 
would be nice if they could post an update here.)