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

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.

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 [] 
Sent: Thursday, September 06, 2012 2:10 PM
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

    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

    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 []
> Sent: Thursday, September 06, 2012 11:17 AM
> To:
> 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:36:15 UTC