Re: Goals of this work (Re: Poll for preferred API alternative)



6 sep 2012 kl. 23:37 skrev "Matthew Kaufman" <matthew.kaufman@skype.net>:

> This of course is NOT reflected in the use case document, which prioritizes all use cases, including PSTN interworking and other legacy software interworking equally, as I believe they should be.

That the main focus has been on securing inivation on tve webplatform, that is between interoperable browsers, has never been in doubt in my eyes (as one of the editors)- the interworking use cases are there as part of the ambition to make interworking usage as steamlined as possible, but not at the expense of the solution for browser to browser usage.

Do I understand it right that U are of another opinion namely that for instance telephony network interworking use cases are as important for tve work in w3c and ietf?

Thanks
Göran



> 
> Perhaps an edit to the "overview" document is required. The W3C use cases is a pointer to the IETF use cases... is there a W3C pointer to the draft you just referenced or is it only an IETF document?
> 
> Matthew Kaufman
> 
> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no] 
> Sent: Thursday, September 06, 2012 2:10 PM
> To: public-webrtc@w3.org
> Subject: Goals of this work (Re: Poll for preferred API alternative)
> 
> Changing the subject line again.
> 
> On 09/06/2012 10:33 PM, Matthew Kaufman wrote:
>> I tried to make this point on the IRC channel of the last call, but clearly it must be made again.
>> 
>> There is nothing in my reading of the use cases that makes the "browser-to-browser" use case *any more or less important than the other use cases*.
>> 
>> Just because we can come up with something with an SDP-like API that follows SDP Offer/Answer-like semantics and has ICE-like NAT traversal and DTLS-SRTP-like security does not in fact mean that we will support any of the other (not "browser-to-browser") use cases. In fact, supporting these cases will become particularly difficult if the SDP diverges, the O/A semantics diverge (as they have already), or the ICE implementation does not have the flexibility to interoperate with pre-final ICE implementations and/or lightweight consent-only gateways. This is precisely what the Microsoft document is talking about when we raise concerns about interoperability. Never mind, of course, that it will take several iterations just to get the SDP actually compatible between two vendor's browsers, if history is any guide.
>> 
>> If you can point me to a specific reference that "the main target for this work is the browser-browser case", please do so.
> From draft-ietf-rtcweb-overview:
> 
> 2.  Principles and Terminology
> 
> 2.1.  Goals of this document
> 
>    The goal of the RTCWEB protocol specification is to specify a set of
>    protocols that, if all are implemented, will allow an implementation
>    to communicate with another implementation using audio, video and
>    data sent along the most direct possible path between the
>    participants.
> 
>    This document is intended to serve as the roadmap to the RTCWEB
>    specifications.  It defines terms used by other pieces of
>    specification, lists references to other specifications that don't
>    need further elaboration in the RTCWEB context, and gives pointers to
>    other documents that form part of the RTCWEB suite.
> 
>    By reading this document and the documents it refers to, it should be
>    possible to have all information needed to implement an RTCWEB
>    compatible implementation.
> 
> 2.2.  Relationship between API and protocol
> 
>    The total RTCWEB/WEBRTC effort consists of two pieces:
> 
>    o  A protocol specification, done in the IETF
> 
>    o  A Javascript API specification, done in the W3C
>       [W3C.WD-webrtc-20120209]
> 
>    Together, these two specifications aim to provide an environment
>    where Javascript embedded in any page, viewed in any compatible
>    browser, when suitably authorized by its user, is able to set up
>    communication using audio, video and auxiliary data, where the
>    browser environment does not constrain the types of application in
>    which this functionality can be used.
> 
>    The protocol specification does not assume that all implementations
>    implement this API; it is not intended to be necessary for
>    interoperation to know whether the entity one is communicating with
>    is a browser or another device implementing this specification.
> 
> The main target of this work is interworking between devices that implement this specification.
> 
>>  Otherwise, I suggest that we work on specifications that make it as easy as possible to implement *all* of the use cases, rather than do what the current specification does which is to make browser-to-browser cases easier *at the expense of* the other use cases.
>> 
>> Matthew Kaufman
>> 
>> -----Original Message-----
>> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
>> Sent: Thursday, September 06, 2012 11:17 AM
>> To: public-webrtc@w3.org
>> Subject: Re: Poll for preferred API alternative
>> 
>> ...
>> I think it is OK if the descriptions must be manipulated for interop (with non-browser end-points) cases; after all, the main target for this work is the browser-browser case.
>> ...
>> 
>> 
> 
> 
>

Received on Thursday, 6 September 2012 21:50:48 UTC