Re: [rtcweb] WGLC: draft-ietf-rtcweb-overview

[Magnus Westerlund <[e-mail]>]

Hi,

Sorry in the delay in responding.

Den 2016-12-09 kl. 16:31, skrev Harald Alvestrand:
> Thank you for the review!
>
> Den 09. des. 2016 15:35, skrev Magnus Westerlund:
>> Hi,
>>
>> I have reviewed the overview document and have the following comments:
>>
>> 1. Section 1:
>>
>>    As the available bandwidth has increased, and as processors an other
>>    hardware has become ever faster, the barriers to participation have
>>    decreased, and it has become possible to deliver a satisfactory
>>    experience on commonly available computing hardware.
>>
>>
>> "processors an other" i guess it should say "and"
>>
>> 2. Section 2.2:
>>
>>    o  A Javascript API specification, done in the W3C
>>       [W3C.WD-webrtc-20120209][W3C.WD-mediacapture-streams-20120628]
>>
>>
>> "A"? Shouldn't this say a "A set of Javascript API specifications, ..."
>> as there are multiple APIs? I know such reformulation would impact the
>> next couple of paragraphs at least. But, maybe some other way of
>> acknowledging the fact that there are multiple API parts?
>
> Actually both the IETF effort and the W3C effort consists of lots of
> moving parts. Would "A Javascript API, defined by a set of
> specifications [cite]" scan better?

Yes, that would at least not create a clash between citations and text.

>
>>
>> 3. Section 2.2:
>>
>> "and the Javascript API defined above."
>>
>> I see a issue with pointing to the specific API specs above. This as if
>> there are other API relatizations defined, even if compatible they are
>> not considered WebRTC Browser. I would suggest, simply drop "defined
>> above".
>
>
> Right, that's what I intended to say, and what I think the WG wanted.
> Unless we can point to a specific API, there's no way to differentiate
> between a WebRTC browser and a WebRTC non-browser.
>
> For a currently interesting example - Edge implements the ORTC API,
> which they believe is implementing the WebRTC protocols, and offering an
> API to them. But it is not the WebRTC API.
>
> So at the moment, I'd want to claim that Edge is a WebRTC non-browser.
> Edge with the 1.0 shim would be a WebRTC browser - and when  Edge
> implements the WebRTC 1.0 natively, Edge would turn into a WebRTC browser.
>
> There are also lots of devices using a C++ API to WebRTC-implementing
> libraries. These cannot make the API security guarantees that the
> rtcweb-security drafts depend on for their design. So I consider it
> appropriate to classify them as WebRTC non-browsers, too.
>
> If this isn't the consensus of the group, we can change it. But it is
> what I intended to write.

Okay, I understand your reasoning. I will not at all persist here.

>
>>
>> 4. On the completeness of the specification
>>
>> Looking at the current set of RTCWeb WG documents, one sees that there
>> are some that are not referenced:
>>
>> draft-ietf-rtcweb-alpn-04
>> draft-ietf-rtcweb-fec-04
>> draft-ietf-rtcweb-ip-handling-02
>
> All of these are indirectly referenced. ALPN is referenced by
> -transport-, and FEC is referenced by -rtp-usage. ip-handling is
> referenced by -jsep-.
>
> Is it necessary to reference them directly? If so, where would you
> suggest that the overview needs text that references them?
>

No, I think we are fine. I just looked at what was not included and then categorized them into the ones referenced somewhere, and the below that wasn't referenced at all.

>>
>> The above are referenced by mentioned documents
>>
>> draft-ietf-rtcweb-sdp-02
>
> That document is only examples. I'm happy to have it only indirectly
> referenced.

Yes, and this appears to be an informative reference for JSEP isn't it?


Merry Christmas and a Happy New Year

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------