From harald@alvestrand.no Sat Jan 1 22:02:49 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F063A684E for ; Sat, 1 Jan 2011 22:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIrvTvIjGLnf for ; Sat, 1 Jan 2011 22:02:48 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 9B8E93A68BF for ; Sat, 1 Jan 2011 22:02:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5908239E091; Sun, 2 Jan 2011 07:04:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEXlaUAPUw-i; Sun, 2 Jan 2011 07:04:26 +0100 (CET) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AAA6C39E082; Sun, 2 Jan 2011 07:04:26 +0100 (CET) Message-ID: <4D201584.9040007@alvestrand.no> Date: Sun, 02 Jan 2011 07:04:52 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-alvestrand-dispatch-rtcweb-datagram X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 06:02:49 -0000 On 12/30/10 16:52, Markus.Isomaki@nokia.com wrote: > Hi, > > A couple of questions and comments on draft-alvestrand-dispatch-rtcweb-datagram-00: > > * Section 4 defines four channel types: UDP, TCP, TLS and DTLS. Is it expected that all clients MUST support all of these? I suppose the reason why both UDP and TCP are included is that depending on the types of middleboxes the peers are behind, they may get just one or the other working. I.e. first try out UDP, if it does not work, attempt TCP. Is that correct? I started out by defining the types I thought might be needed - so this is not the "must implement" list. The "Must implement" list is still a matter for discussion - not having UDP in there is certainly a non-starter, so UDP has to be "must implement". For others, I'd like to see arguments. > * Section 4.5 states that TURN and relaying are needed. How about things like HTTP/TLS tunneling? In many cases that is the only way to get the transport channel working. TURN may be helpful in some, hopefully increasing, amount of cases, but that alone will still leave a lot of corporate users unserved. At Google, we've implemented a form of HTTP/TLS tunnelling using a TURN variant (see libjingle source for details), so I didn't differentiate between those options - I see HTTP/TLS as a form of relaying; I don't believe simultaneous-open TCP is going to work reliably enough for our purposes. > * Section 3 mentions that things like pseudoTCP can be run over the datagram transport. In case only UDP works end-to-end that seems useful. However, if we can get a "native" TCP connection up, it seems natural to use that as is rather than via some kind of generic datagram abstraction layer. I think we probably should define both datagram and bytestream services separately. Bytestream would be either TCP or pseudoTCP/UDP. If we only do datagram service, leave the whole pseudoTCP reference out. I agree with your way of putting it. The reference is intended as informative; bytestream COULD be layered over the datagram service, but doesn't need to be. Background: I had a discussion with a coworker who wanted to have a single API to both streaming and datagram service; I believe it makes more sense to define an API to a datagram service and an API to a streaming service separately - the big argument for PseudoTCP is the client-to-client connection case, where one often finds that UDP works and TCP doesn't. The argument for defining TCP over datagram, rather than TCP over UDP, is that we might easily find ourselves needing functions like ICE establishment or TURN relaying for client-to-client TCP sessions; doing it this way saves us one duplicate reference set. (The concept of pseudoTCP running over datagrams tunneled over HTTP/TLS somewhat boggles the mind, though....) > * Section 6 defines a URI with a number of IP address:transport:port candidates. I'm not too clear on how that URI would be used. It looks to me as something that is received as a result of gathering the candidates (with STUN, TURN etc.) as the first step of ICE. If Jingle or SDP offer/answer or some proprietary protocol were used to pass the candidate information to the other peer, that information would be encoded according to that particular protocol. So is this specific URI just meant for local representation at the API and not something that is passed over the network as such? What's the need or benefit of making it a URI? This is an example of speculative standardization, or "trial balloon" - W3C folks have had a habit of using URIs for any form of structured parameter in APIs; if that is what the W3C effort concludes that they want, this is intended to show that it can be given to them. That said - the fact that this is intended to represent, exactly, the semantics of a=candidate lines from SDP needs to be made clear (as I said in another thread). Let's not have more different semantics than we need to. > Thanks, > Markus Thanks for the review1 > > > From harald@alvestrand.no Sat Jan 1 22:42:57 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118993A698C for ; Sat, 1 Jan 2011 22:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O948uY-GzA53 for ; Sat, 1 Jan 2011 22:42:55 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 1CA4D3A684E for ; Sat, 1 Jan 2011 22:42:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D854739E091; Sun, 2 Jan 2011 07:44:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKBQhM4s-CuE; Sun, 2 Jan 2011 07:44:37 +0100 (CET) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 289DF39E082; Sun, 2 Jan 2011 07:44:37 +0100 (CET) Message-ID: <4D201EEE.7030000@alvestrand.no> Date: Sun, 02 Jan 2011 07:45:02 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtc-web@alvestrand.no, dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 06:42:57 -0000 On 12/30/10 17:10, Markus.Isomaki@nokia.com wrote: > Hi, > > A few comments and questions on rtcweb-protocols-00: > > In general I believe we need a framework document that describes how the various protocol and API specs are used to build an interoperable "RTC-Web" implementation. In my opinion that document should not be like RFC 5411 (Hitchhiker's guide to SIP), which is merely listing of different SIP related standards. Instead, the RTC-Web framework document should define what is the minimum set that everyone needs to implement to get interop at a reasonable level. (What that reasonable level is needs to be agreed upon, of course. I assume it includes at least transport and NAT traversal for audio/video streams.) I agree, and that is where I want this to go. In addition, we need use case documentation that allows us to verify that the use cases we envision are satisfiable within the framework. > I understand that the current document is not yet intended for that purpose, but it is just trying to get discussion started. But if we pick this draft as a baseline going forward, it would be useful to make the use of language more consistent. At the moment some things are defined with "MUST" statements while others are more vague. I think the "MUST" statements are good and everything that is really required by an implementation needs to be expressed that way. (It is naturally good to have some descriptive text around the exact requirements, as long as the requirements are clear.) Yes, the vagueness is in direct proportion to how far I'm away from being able to read some sort of consensus that stuff needs inclusion. As discussion goes forward, I expect it to be sharpened. Note that even the MUSTs are merely trial balloons at the moment - I wouldn't be unhappy with carrying most of them forward, but it is highly likely that some of them are wrong, and others may want to be left open rather than mandated. Discussion will show. > Section 4 defines data framing and security. I believe the challenging part of data framing will be to ensure we get the video calls interoperable. I don't have that much experience on the details, but I know that getting RTP/AVPF stuff implemented and interoperable is not that trivial. Various groups such as IMTC and UCIF have worked on interoperability profiles for video calls. The easy approach might be just to mandate the basics (RTP/AVP), get that well working across browsers and then extend based on that experience. If those other groups come up with something useful and public, those profiles could be borrowed. Agreed 100%. It might even help interoperability. Do you have citable references to the current state of that work? I'm worried about not including AVPF, since there is stuff in AVPF (including the various NACKs and reference frame requests) that is vital for getting efficient reliable communication over lossy networks using some of the potential codecs. Matter for further discussion. > Section 6 is about connection management. That will be the really hard part of this exercise. I do support the notion that at least initially we should focus on transport, framing and formats of media, and say that those can be setup in proprietary ways (presumably the browser using HTTP or websocket as transport for the actual setup). For that the APIs would "only" need to support what is input/output to ICE/STUN/TURN and codec selection, while the rest happens in Javascript within the application. But going forward I think we do need to pick up either SIP/SDP or XMPP/Jingle as the baseline, in order to make things easy to use. If we can have a common definition of "connection" that we can offer up (through APIs) to SIP/SDP engines or XMPP/Jingle engines as "the object to be manipulated", I think we've already won a lot. I don't want to trap us at the forefront of more battlefronts than we have to have. While it would be nice to have only one engine to relate to, I am afraid of bringing this discussion into this group. > Markus > > From stefan.lk.hakansson@ericsson.com Sat Jan 1 23:41:47 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1C903A698C for ; Sat, 1 Jan 2011 23:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt7kJklap6+6 for ; Sat, 1 Jan 2011 23:41:45 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 68C993A68D7 for ; Sat, 1 Jan 2011 23:41:45 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-c0-4d202cb6f0d0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E4.B3.13987.6BC202D4; Sun, 2 Jan 2011 08:43:50 +0100 (CET) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.190]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sun, 2 Jan 2011 08:43:50 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Harald Alvestrand , "Markus.Isomaki@nokia.com" Date: Sun, 2 Jan 2011 08:43:49 +0100 Thread-Topic: [RTW] Comments on draft-alvestrand-dispatch-rtcweb-protocols-00 Thread-Index: AcuqSJijmYdhf0W0QgSyEnWPPUoAswAB2MzA Message-ID: References: <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com> <4D201EEE.7030000@alvestrand.no> In-Reply-To: <4D201EEE.7030000@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Sun, 02 Jan 2011 09:42:34 -0800 Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" Subject: Re: [dispatch] [RTW] Comments on draft-alvestrand-dispatch-rtcweb-protocols-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 07:41:48 -0000 >>In general I believe we need a framework document that describes how=20 >>the various protocol and API specs are used to build an interoperable=20 >>"RTC-Web" implementation. In my opinion that document should not be=20 >>like RFC 5411 (Hitchhiker's guide to SIP), which is merely listing of=20 >>different SIP related standards. Instead, the RTC-Web framework=20 >>document should define what is the minimum set that everyone needs to=20 >>implement to get interop at a reasonable level. (What that reasonable=20 >>level is needs to be agreed upon, of course. I assume it includes at=20 >>least transport and NAT traversal for audio/video streams.) >I agree, and that is where I want this to go. In addition, we need use cas= e documentation that allows us to verify that >the use cases we envision ar= e satisfiable within the framework. We also need to decide were such a FW doc should be developed. IETF could b= e a natural place, but it is quite close in definition to the "Profile" rec= ommendation proposed by the draft W3C charter. //Stefan > -----Original Message----- > From: rtc-web-bounces@alvestrand.no=20 > [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Harald Alvestrand > Sent: den 2 januari 2011 07:45 > To: Markus.Isomaki@nokia.com > Cc: rtc-web@alvestrand.no; dispatch@ietf.org > Subject: Re: [RTW] Comments on=20 > draft-alvestrand-dispatch-rtcweb-protocols-00 >=20 > On 12/30/10 17:10, Markus.Isomaki@nokia.com wrote: > > Hi, > > > > A few comments and questions on rtcweb-protocols-00: > > > > In general I believe we need a framework document that=20 > describes how=20 > > the various protocol and API specs are used to build an=20 > interoperable=20 > > "RTC-Web" implementation. In my opinion that document should not be=20 > > like RFC 5411 (Hitchhiker's guide to SIP), which is merely=20 > listing of=20 > > different SIP related standards. Instead, the RTC-Web framework=20 > > document should define what is the minimum set that=20 > everyone needs to=20 > > implement to get interop at a reasonable level. (What that=20 > reasonable=20 > > level is needs to be agreed upon, of course. I assume it=20 > includes at=20 > > least transport and NAT traversal for audio/video streams.) > I agree, and that is where I want this to go. In addition, we=20 > need use case documentation that allows us to verify that the=20 > use cases we envision are satisfiable within the framework. > > I understand that the current document is not yet intended for that=20 > > purpose, but it is just trying to get discussion started. But if we=20 > > pick this draft as a baseline going forward, it would be useful to=20 > > make the use of language more consistent. At the moment some things=20 > > are defined with "MUST" statements while others are more vague. I=20 > > think the "MUST" statements are good and everything that is really=20 > > required by an implementation needs to be expressed that=20 > way. (It is=20 > > naturally good to have some descriptive text around the exact=20 > > requirements, as long as the requirements are clear.) > Yes, the vagueness is in direct proportion to how far I'm=20 > away from being able to read some sort of consensus that=20 > stuff needs inclusion. As discussion goes forward, I expect=20 > it to be sharpened. > Note that even the MUSTs are merely trial balloons at the=20 > moment - I wouldn't be unhappy with carrying most of them=20 > forward, but it is highly likely that some of them are wrong,=20 > and others may want to be left open rather than mandated.=20 > Discussion will show. > > Section 4 defines data framing and security. I believe the=20 > challenging part of data framing will be to ensure we get the=20 > video calls interoperable. I don't have that much experience=20 > on the details, but I know that getting RTP/AVPF stuff=20 > implemented and interoperable is not that trivial. Various=20 > groups such as IMTC and UCIF have worked on interoperability=20 > profiles for video calls. The easy approach might be just to=20 > mandate the basics (RTP/AVP), get that well working across=20 > browsers and then extend based on that experience. If those=20 > other groups come up with something useful and public, those=20 > profiles could be borrowed. > Agreed 100%. It might even help interoperability. Do you have=20 > citable references to the current state of that work? > I'm worried about not including AVPF, since there is stuff in=20 > AVPF (including the various NACKs and reference frame=20 > requests) that is vital for getting efficient reliable=20 > communication over lossy networks using some of the potential=20 > codecs. Matter for further discussion. > > Section 6 is about connection management. That will be the=20 > really hard part of this exercise. I do support the notion=20 > that at least initially we should focus on transport, framing=20 > and formats of media, and say that those can be setup in=20 > proprietary ways (presumably the browser using HTTP or=20 > websocket as transport for the actual setup). For that the=20 > APIs would "only" need to support what is input/output to=20 > ICE/STUN/TURN and codec selection, while the rest happens in=20 > Javascript within the application. But going forward I think=20 > we do need to pick up either SIP/SDP or XMPP/Jingle as the=20 > baseline, in order to make things easy to use. > If we can have a common definition of "connection" that we=20 > can offer up (through APIs) to SIP/SDP engines or XMPP/Jingle=20 > engines as "the object to be manipulated", I think we've=20 > already won a lot. I don't want to trap us at the forefront=20 > of more battlefronts than we have to have.=20 > While it would be nice to have only one engine to relate to,=20 > I am afraid of bringing this discussion into this group. > > Markus > > > > >=20 > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > = From stefan.lk.hakansson@ericsson.com Wed Jan 5 04:31:11 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193063A6B84 for ; Wed, 5 Jan 2011 04:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4RL7W3b3x2i for ; Wed, 5 Jan 2011 04:31:08 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id F03713A6B74 for ; Wed, 5 Jan 2011 04:31:07 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-64-4d2465091017 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 63.89.23694.905642D4; Wed, 5 Jan 2011 13:33:14 +0100 (CET) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.190]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 5 Jan 2011 13:33:13 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Matthew Kaufman , "RTC-Web@alvestrand.no" , "dispatch@ietf.org" Date: Wed, 5 Jan 2011 13:33:12 +0100 Thread-Topic: [RTW] peer-to-peer connection API thoughts Thread-Index: AcusfHvAbXrPwvj9Sg+FTaCPU3e4jwAV3byw Message-ID: References: <4D23D0E9.1060300@skype.net> In-Reply-To: <4D23D0E9.1060300@skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] [RTW] peer-to-peer connection API thoughts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 12:31:11 -0000 Hi Matthew, good input. I agree to your baseline points. Regarding API design in general, I think that it is important that we get f= eedback from web developers and browser vendors, so API design related disc= ussions should happen in the W3C space in my view. For the peer-to-peer connection API, a lot of what you bring up is related = to functional split between the web app, the browser and the rendezvous/hel= per server. If I understand correctly, B and E would, apart from the web server only ne= ed a STUN (possibly TURN, but in the simplest case only STUN) server as sup= port. Find and connect is handled by the application. A, C and D would need= more functionality in the network (rendezvous). What has been discussed so far is more in the lines of B and E, and I think= that is the path we should follow.=20 We are doing some testing with the ConnectionPeer API, which is to my under= standing close to B in your list, as descibed in the WhatWG html draft (htt= p://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#peer= -to-peer-connections). I will come back with some experiences from that wor= k shortly. Br, Stefan=20 > -----Original Message----- > From: rtc-web-bounces@alvestrand.no=20 > [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Matthew Kaufman > Sent: den 5 januari 2011 03:01 > To: RTC-Web@alvestrand.no > Subject: [RTW] peer-to-peer connection API thoughts >=20 > I spent the holidays thinking about various ways of dealing=20 > with the connection API problem, and I thought I might put=20 > those thoughts out for some discussion rather than trying to=20 > pick one and write it up as a draft specification. >=20 > There's obviously a few models one might build upon for how=20 > to represent the peer-to-peer connections and bring them to=20 > life. The WebSockets API (=20 > http://dev.w3.org/html5/websockets/ ) is a solution to the=20 > client-server connection problem, and the way Flash Player=20 > extended its NetConnection and NetStream objects to support=20 > peer-to-peer connectivity over RTMFP (=20 > http://help.adobe.com/en_US/FlashPlatform/reference/actionscri > pt/3/flash/net/NetStream.html > ) is another model. And of course > draft-alvestrand-dispatch-rtcweb-datagram (=20 > http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-da > tagram-00 > ) hints at how a URL scheme might be applied to some of this problem. >=20 > I believe the following items are givens, though feedback is=20 > of course welcome on these points as well: >=20 > 1. When it is possible to establish a peer-to-peer connection=20 > for media, that should be supported (and is probably preferred) >=20 > 2. Supporting peer-to-peer connections for media in the face=20 > of NA(P)T and firewalls will require UDP, and UDP=20 > hole-punching techniques (UDP is also preferable for=20 > delay-sensitive media) >=20 > 3. Enabling a browser to send UDP datagrams to script- or=20 > server-designated IP addresses and ports is unsafe unless a=20 > handshake is used to verify that the other end is a willing=20 > participant >=20 > 4. STUN Connectivity Check probes and responses (with short-term > credentials) are a sufficiently strong handshake for the=20 > above (and this then suggests that ICE or a variant thereof=20 > is a good approach for the NAT traversal) >=20 > 5. Given NAT and firewalls, it will also be necessary to=20 > support relayed UDP traffic; that is to say, a traffic flow=20 > which is peer-relay server-peer >=20 > 6. Given NAT and firewalls, it will further be necessary to=20 > support transporting the same media traffic over a TCP=20 > connection, for cases where UDP is blocked. This could be a=20 > TCP tunnel of the UDP datagrams, WebSockets, or something else. >=20 > ----- >=20 >=20 > A few possible programming models to support this then=20 > present themselves, though this is by no means an exhaustive list... >=20 > A. A single connection object which can magically make everything work >=20 > In this scenario the API is essentially "var connection =3D new=20 > PeerConnection(destinationSpecifier);". >=20 > The destinationSpecifier would contain enough information for=20 > the PeerConnection object's implementation to: use ICE to=20 > attempt to open a direct or relayed connection over UDP, or=20 > failing that, TCP. It would contain the information necessary=20 > to communicate with an intermediary server as the ICE=20 > negotiation proceeds as well (a "low bandwidth"=20 > signaling channel is required between a pair of peers in many=20 > cases for exchange of pertinent information before the media=20 > connection can be established). >=20 > B. A single connection object which does most of the magic,=20 > but with the low-bandwidth signaling made external though events >=20 > In this case, the API is the same as above, but rather than=20 > providing in the destiniationSpecifier some sort of server=20 > address for the "low bandwidth signaling" the connection=20 > object would instead fire events containing (essentially=20 > opaque to the channel, but in an agreed format) the data=20 > which needed to be transported to the other side. A=20 > corresponding API on the far end's "listening" connection=20 > object would allow for the data to be injected at the far=20 > end. The script implementer would simply need to wire the=20 > event up to an existing transport mechanism (HTTP, WebSockets). >=20 > C. A connection object which does most of the magic, but with=20 > a parent object that is the connection to the signaling mechanism >=20 > This is the approach Flash Player has taken. The=20 > NetConnection is opened to the rendezvous-handling server=20 > (which can also act as a media relay), NetStreams are then=20 > opened either to that relaying server or directly to other=20 > peers. These peer-to-peer NetStreams use the open=20 > NetConnection for the peer setup signaling (determining the=20 > far IP addresses, requesting NAT hole-punching, etc.) >=20 > D. Multiple connection objects >=20 > In this case, the API is similar to case A for the UDP=20 > peer-to-peer channel but a *different* API and connection=20 > object (perhaps an extension of the existing WebSocket API)=20 > is used for the client-server fallback cases. This requires=20 > the script to determine when a direct connection cannot be=20 > made (which sometimes cannot be determined without trying it=20 > out). Makes the programming model more complex, but avoids=20 > duplication, as existing client-server models can be used for=20 > all relayed (and server-based) media cases without there=20 > being two (or more) different ways to move real-time media=20 > from a server to a browser (and vice versa). >=20 > E. Script-intensive (but flexible) components >=20 > In this model, an API exists which exposes a nearly bare UDP=20 > socket, but with permissions restricted such that traffic may=20 > not be sent unless handshake probes are sent and received.=20 > Maximum flexibility, at some significant cost in script=20 > complexity (though this could be encapsulated into=20 > well-known, even open-source, libraries). >=20 > An example API for this is would be: > var connection =3D new PeerConnection(ICEusernameString,=20 > ICEpasswordString); > opens the local UDP port, nothing is permitted at this point > PeerConnection.testConnectivity(farSockaddrString,=20 > farUsernameString, farPasswordString); > sends STUN connectivity checks > PeerConnection.onConnectivityTest(receivedSockaddrString,=20 > usenameString); > event that fires when a connectivity test is received=20 > with valid credentials. Browser also automatically generates=20 > the transaction response. > PeerConnection.onConnectivitySuccess(receivedSockaddrString, > reflexiveAddrString, usernameString); > event that fires when the connectivity test transaction=20 > response arrives... Browser then adds this destination to a=20 > whitelist of addresses that media streams may be sent to > PeerConnection.openMediaSession(sockaddrString) > fails immediately if the address isn't on the=20 > whitelist, otherwise starts a DTLS handshake with the=20 > specified address >=20 > ---- >=20 > Hopefully this will stimulate discussion and/or additional=20 > ideas from other folks who are working on designing and/or=20 > implementing solutions to this problem. >=20 > Matthew Kaufman > matthew.kaufman@skype.net > Skype: atmatthewat >=20 >=20 > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > = From mary.ietf.barnes@gmail.com Wed Jan 5 13:51:33 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B403A6BA8 for ; Wed, 5 Jan 2011 13:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.838 X-Spam-Level: X-Spam-Status: No, score=-102.838 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgfGdZSFzxmp for ; Wed, 5 Jan 2011 13:51:31 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 43B4D3A67D6 for ; Wed, 5 Jan 2011 13:51:31 -0800 (PST) Received: by gxk28 with SMTP id 28so7351336gxk.31 for ; Wed, 05 Jan 2011 13:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=niPu5bn7D+XEE4ekDnYFFUd08uSTLzOhCihY9OddlPM=; b=WLdQsEiKeWCsd7S9VeZoS3sUdfWp4JdhilxukwHI4ZZIygTFUCwLF6tVAHbJpwgPfX m+GY1eY9wmSk0n57QH18NZT3J5fx2/5NvN9jy8s7M7RaYA1m5traoQWHuup4OdNGf/QB izZ+z4ypsnEC5ZKHsKnh5Nns4PPcrrshSkpb0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=O4sqYXNnsifOsnuPNDM7BsS90u1X9vdOX3CSdLWJgcikjCjr3HLhy04SXWhZwiC5YV OBTC66ob23iyJf4TCfHnja7gVMw0Xb6UsXoVlgzVb6Vl6Uv68jPGw3LFGGU92EnLeRUF x4UreRNCH7oB+v85TXv+oRkQJRQD8LIKiuYIg= MIME-Version: 1.0 Received: by 10.236.103.145 with SMTP id f17mr12175582yhg.61.1294264417835; Wed, 05 Jan 2011 13:53:37 -0800 (PST) Received: by 10.236.95.35 with HTTP; Wed, 5 Jan 2011 13:53:37 -0800 (PST) Date: Wed, 5 Jan 2011 15:53:37 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=0023547c9023dee2910499206a82 Subject: [dispatch] Reminder: Deadlines for DISPATCH @ IETF-80 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:51:33 -0000 --0023547c9023dee2910499206a82 Content-Type: text/plain; charset=ISO-8859-1 Per the note below, the deadlines for BoF proposals is January 31st. The DISPATCH WG topic deadlines for IETF-80, per http://trac.tools.ietf.org/wg/dispatch/trac/wiki, are set based on that deadline as summarized below. So, there is less than two weeks left to notify the chairs of topics targeted for discussion leading up to and during the IETF-80 DISPATCH WG session. Regards, Mary. DISPATCH WG co-chair * *Jan 17th, 2011*. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [*Two weeks prior to BoF proposal deadline*, 7 weeks before -00 deadline] * *Jan 24th, 2011*. Cutoff for charter proposals for topics. [*One week prior to BoF proposal deadline*, two weeks before announcement of topics] * *Feb 7th, 2011*. Topics that are to be the focus of IETF-79 are announced. [*Typically one week before AD BoF approval and deadline to request WG slot*, 4 weeks before -00 deadline] * *March 6th, 2011*. -00 draft deadline. * *March 13th, 2011*. Draft deadline. ---------- Forwarded message ---------- From: Jari Arkko Date: Wed, Jan 5, 2011 at 3:29 PM Subject: time to act on IETF-80 BOFs To: IETF Discussion , Working Group Chairs Just as a reminder, if any of you are thinking of proposing new IETF work: the deadline for BOF proposals for the next meeting is January 31st. But if you have something in mind, please talk to your ADs as soon as possible. More information at http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --0023547c9023dee2910499206a82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Per the note below, the deadlines for BoF proposals is January 31st. The DI= SPATCH WG topic deadlines for IETF-80, per http://trac.tools.ietf.org/wg/dispatch/trac/wi= ki,=A0are set based on that deadline as summarized below. =A0So, there = is less than two weeks left to notify the chairs of topics targeted for dis= cussion leading up to and during the IETF-80 DISPATCH WG session.=A0

Regards,
Mary.
DISPATCH WG co-chair
<= div>
*=A0Jan 17th, 2011. Cutoff date to notify the chair= s/DISPATCH WG of plans to submit a proposal. [Two weeks prior to BoF pro= posal deadline, 7 weeks before -00 deadline]

*=A0Jan 24th, 20= 11. Cutoff for charter proposals for topics. [One week prior to= BoF proposal deadline, two weeks before announcement of topics]

*=A0Feb 7th, 2011. Topics that are to be the focus of I= ETF-79 are announced. [Typically one week before AD BoF approval and dea= dline to request WG slot, 4 weeks before -00 deadline]

*=A0March 6th, 2011. -00 draft deadline.

*=A0March 13th, 2011. Draft deadline.



---------- Forwarded message -------= ---
From: Jari Arkko <jari.arkko@piuha.net>
Date: Wed, Jan 5, 2011 at 3:29 PM
Subject: time to act on IETF-80 BOFsTo: IETF Discussion <ietf@ietf.org>, Working Group Chairs <wgchai= rs@ietf.org>


Just as a reminder, if any of you are thinking of proposing new IET= F
work: the deadline for BOF proposals for the next meeting is January
31st. But if you have something in mind, please talk to your ADs as soon as possible. More information at
http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80<= br>
Jari

_______________________________________________
Ietf mailing list
Ietf@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ietf

--0023547c9023dee2910499206a82-- From juberti@google.com Wed Jan 5 23:03:45 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6233E3A6B1F for ; Wed, 5 Jan 2011 23:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.176 X-Spam-Level: X-Spam-Status: No, score=-104.176 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmL476LC6x9W for ; Wed, 5 Jan 2011 23:03:42 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4CBDC3A6B1D for ; Wed, 5 Jan 2011 23:03:41 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p0675lCr023547 for ; Wed, 5 Jan 2011 23:05:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294297547; bh=7RCR+lrxA8USdPUKQJTTga2sM3w=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=QG6fcSdam61XCpRdADPoGaBR0YRpgM+rfhHpXzMkoSLK08L6901+158hU+Pz6Fyss QjW9qDv1q5HcNOmKQulBA== Received: from qyk36 (qyk36.prod.google.com [10.241.83.164]) by wpaz13.hot.corp.google.com with ESMTP id p0675kwj009295 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 5 Jan 2011 23:05:46 -0800 Received: by qyk36 with SMTP id 36so16116488qyk.6 for ; Wed, 05 Jan 2011 23:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=Bnmitds4/7WaCslvlZJiZCF52l3fz7gba0m47ZamLDg=; b=x+ejcpO1sCMJhmWEpFOgZnagnHgR1Bv+ayTC9iPkVD+iQ54Kfatj/dnaG/xMh6nAS1 cW89WdsLJojIESWK++pw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=hOOT4LGpz8WQuKrdDzuoPXGfu0yU1Lpc9yNTdsBK4ExhQ3F/CgnW288kUbRCDlth26 60MUSKFw5SvAOzD3VDfw== Received: by 10.229.82.70 with SMTP id a6mr21315145qcl.75.1294297546000; Wed, 05 Jan 2011 23:05:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.135.9 with HTTP; Wed, 5 Jan 2011 23:05:25 -0800 (PST) In-Reply-To: <4D201584.9040007@alvestrand.no> References: <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com> <4D201584.9040007@alvestrand.no> From: Justin Uberti Date: Wed, 5 Jan 2011 23:05:25 -0800 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=00163646d04e768817049928215a X-System-Of-Record: true Cc: rtc-web@alvestrand.no, dispatch@ietf.org, Markus.Isomaki@nokia.com Subject: Re: [dispatch] [RTW] Comments on draft-alvestrand-dispatch-rtcweb-datagram X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 07:03:45 -0000 --00163646d04e768817049928215a Content-Type: text/plain; charset=UTF-8 On Sat, Jan 1, 2011 at 10:04 PM, Harald Alvestrand wrote: > On 12/30/10 16:52, Markus.Isomaki@nokia.com wrote: > >> Hi, >> >> A couple of questions and comments on >> draft-alvestrand-dispatch-rtcweb-datagram-00: >> >> * Section 4 defines four channel types: UDP, TCP, TLS and DTLS. Is it >> expected that all clients MUST support all of these? I suppose the reason >> why both UDP and TCP are included is that depending on the types of >> middleboxes the peers are behind, they may get just one or the other >> working. I.e. first try out UDP, if it does not work, attempt TCP. Is that >> correct? >> > I started out by defining the types I thought might be needed - so this is > not the "must implement" list. The "Must implement" list is still a matter > for discussion - not having UDP in there is certainly a non-starter, so UDP > has to be "must implement". For others, I'd like to see arguments. > > * Section 4.5 states that TURN and relaying are needed. How about things >> like HTTP/TLS tunneling? In many cases that is the only way to get the >> transport channel working. TURN may be helpful in some, hopefully >> increasing, amount of cases, but that alone will still leave a lot of >> corporate users unserved. >> > At Google, we've implemented a form of HTTP/TLS tunnelling using a TURN > variant (see libjingle source for details), so I didn't differentiate > between those options - I see HTTP/TLS as a form of relaying; I don't > believe simultaneous-open TCP is going to work reliably enough for our > purposes. > > * Section 3 mentions that things like pseudoTCP can be run over the >> datagram transport. In case only UDP works end-to-end that seems useful. >> However, if we can get a "native" TCP connection up, it seems natural to use >> that as is rather than via some kind of generic datagram abstraction layer. >> I think we probably should define both datagram and bytestream services >> separately. Bytestream would be either TCP or pseudoTCP/UDP. If we only do >> datagram service, leave the whole pseudoTCP reference out. >> > I agree with your way of putting it. The reference is intended as > informative; bytestream COULD be layered over the datagram service, but > doesn't need to be. > The issue with a "native" TCP connection is that we need to perform ICE-y checks on it to enforce the same-origin policy. When using PseudoTCP, the ICE checks are done automatically as part of the datagram protocol. However, as Harald points out, if we are using the "native" TCP for a connection to a relay or conference server, we can simply run our datagram protocol over top of the native TCP connection. Basically what I am saying is that while we may use "native" TCP connections internally for handling scenarios where UDP is blocked, I'm not sure we can expose them from the API. > > Background: I had a discussion with a coworker who wanted to have a single > API to both streaming and datagram service; I believe it makes more sense to > define an API to a datagram service and an API to a streaming service > separately - the big argument for PseudoTCP is the client-to-client > connection case, where one often finds that UDP works and TCP doesn't. > I had been thinking the datagram and streaming services should use a single API - much of the API ends up being the same, and that's how BSD sockets work. There are a few differences for streaming services, but they are mostly (entirely?) additive (flow control being the main one). > > The argument for defining TCP over datagram, rather than TCP over UDP, is > that we might easily find ourselves needing functions like ICE establishment > or TURN relaying for client-to-client TCP sessions; doing it this way saves > us one duplicate reference set. (The concept of pseudoTCP running over > datagrams tunneled over HTTP/TLS somewhat boggles the mind, though....) > > * Section 6 defines a URI with a number of IP address:transport:port >> candidates. I'm not too clear on how that URI would be used. It looks to me >> as something that is received as a result of gathering the candidates (with >> STUN, TURN etc.) as the first step of ICE. If Jingle or SDP offer/answer or >> some proprietary protocol were used to pass the candidate information to the >> other peer, that information would be encoded according to that particular >> protocol. So is this specific URI just meant for local representation at the >> API and not something that is passed over the network as such? What's the >> need or benefit of making it a URI? >> > This is an example of speculative standardization, or "trial balloon" - W3C > folks have had a habit of using URIs for any form of structured parameter in > APIs; if that is what the W3C effort concludes that they want, this is > intended to show that it can be given to them. > That said - the fact that this is intended to represent, exactly, the > semantics of a=candidate lines from SDP needs to be made clear (as I said in > another thread). Let's not have more different semantics than we need to. > >> Thanks, >> Markus >> > Thanks for the review1 > > > >> >> >> > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web > --00163646d04e768817049928215a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Jan 1, 2011 at 10:04 PM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:
On 12/30/10 16:52, Markus.Isomaki@nokia.com wrote:
Hi,

A couple of questions and comments on draft-alvestrand-dispatch-rtcweb-data= gram-00:

* Section 4 defines four channel types: UDP, TCP, TLS and DTLS. Is it expec= ted that all clients MUST support all of these? I suppose the reason why bo= th UDP and TCP are included is that depending on the types of middleboxes t= he peers are behind, they may get just one or the other working. I.e. first= try out UDP, if it does not work, attempt TCP. Is that correct?
I started out by defining the types I thought might be needed - so this is = not the "must implement" list. The "Must implement" lis= t is still a matter for discussion - not having UDP in there is certainly a= non-starter, so UDP has to be "must implement". For others, I= 9;d like to see arguments.

* Section 4.5 states that TURN and relaying are needed. How about things li= ke HTTP/TLS tunneling? In many cases that is the only way to get the transp= ort channel working. TURN may be helpful in some, hopefully increasing, amo= unt of cases, but that alone will still leave a lot of corporate users unse= rved.
At Google, we've implemented a form of HTTP/TLS tunnelling using a TURN= variant (see libjingle source for details), so I didn't differentiate = between those options - I see HTTP/TLS as a form of relaying; I don't b= elieve simultaneous-open TCP is going to work reliably enough for our purpo= ses.

* Section 3 mentions that things like pseudoTCP can be run over the datagra= m transport. In case only UDP works end-to-end that seems useful. However, = if we can get a "native" TCP connection up, it seems natural to u= se that as is rather than via some kind of generic datagram abstraction lay= er. I think we probably should define both datagram and bytestream services= separately. Bytestream would be either TCP or pseudoTCP/UDP. If we only do= datagram service, leave the whole pseudoTCP reference out.
I agree with your way of putting it. The reference is intended as informati= ve; bytestream COULD be layered over the datagram service, but doesn't = need to be.

The issue with a "nati= ve" TCP connection is that we need to perform ICE-y checks on it to en= force the same-origin policy. When using PseudoTCP, the ICE checks are done= automatically as part of the datagram protocol. However, as Harald points = out, if we are using the "native" TCP=C2=A0for a connection to a = relay or conference server, we can simply run our datagram protocol over to= p of the native TCP connection.=C2=A0

Basically what I am saying is that while we may use &qu= ot;native" TCP connections internally for handling scenarios where UDP= is blocked, I'm not sure we can expose them from the API.

Background: I had a discussion with a coworker who wanted to have a single = API to both streaming and datagram service; I believe it makes more sense t= o define an API to a datagram service and an API to a streaming service sep= arately - the big argument for PseudoTCP is the client-to-client connection= case, where one often finds that UDP works and TCP doesn't.

I had been thinking the datagram and strea= ming services should use a single API - much of the API ends up being the s= ame, and that's how BSD sockets work. There are a few differences for s= treaming services, but they are mostly (entirely?) additive (flow control b= eing the main one).

The argument for defining TCP over datagram, rather than TCP over UDP, is t= hat we might easily find ourselves needing functions like ICE establishment= or TURN relaying for client-to-client TCP sessions; doing it this way save= s us one duplicate reference set. (The concept of pseudoTCP running over da= tagrams tunneled over HTTP/TLS somewhat boggles the mind, though....)

* Section 6 defines a URI with a number of IP address:transport:port candid= ates. I'm not too clear on how that URI would be used. It looks to me a= s something that is received as a result of gathering the candidates (with = STUN, TURN etc.) as the first step of ICE. If Jingle or SDP offer/answer or= some proprietary protocol were used to pass the candidate information to t= he other peer, that information would be encoded according to that particul= ar protocol. So is this specific URI just meant for local representation at= the API and not something that is passed over the network as such? What= 9;s the need or benefit of making it a URI?
This is an example of speculative standardization, or "trial balloon&q= uot; - W3C folks have had a habit of using URIs for any form of structured = parameter in APIs; if that is what the W3C effort concludes that they want,= this is intended to show that it can be given to them.
That said - the fact that this is intended to represent, exactly, the seman= tics of a=3Dcandidate lines from SDP needs to be made clear (as I said in a= nother thread). Let's not have more different semantics than we need to= .
Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0Markus
Thanks for the review1






_______________________________________________
RTC-Web mailing list
RTC-Web@alvestra= nd.no
http://www.alvestrand.no/mailman/listinfo/rtc-web

--00163646d04e768817049928215a-- From harald@alvestrand.no Thu Jan 6 03:52:05 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7046F3A6B74 for ; Thu, 6 Jan 2011 03:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysYoYtsS0ASh for ; Thu, 6 Jan 2011 03:51:34 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id A84373A6F01 for ; Thu, 6 Jan 2011 03:51:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1AFBF39E0FA; Thu, 6 Jan 2011 12:53:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hROgES2y2KR; Thu, 6 Jan 2011 12:53:14 +0100 (CET) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5492A39E074; Thu, 6 Jan 2011 12:53:14 +0100 (CET) Message-ID: <4D25AD41.7060306@alvestrand.no> Date: Thu, 06 Jan 2011 12:53:37 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "'dispatch@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtc-web@alvestrand.no" Subject: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 11:52:05 -0000 This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized). This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality. The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado: ------------------------------------- Version: 2 Possible Names: Body: Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser. Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human. The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming. This working group will select and define a minimal set of protocols that will enable browsers to: * have interactive real time voice and video between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set: 1) RTP/ RTCP 2) a baseline audio codec for high quality interactive audio. Opus will be considered as one of the candidates 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered 4) a baseline video codec. H.264 and VP8 will be considered 5) Diffserv based QoS 6) NAT traversal using ICE 7) RFC 4833 based DTMF transport 8) RFC 4574 based Label support for identifying streams purpose 9) Secure RTP and keying 10) support for IPv4, IPv6 and dual stack browsers The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state. The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocation, IM & Presence, NSIS, Resource Priority, Milestones: February 2011 Candidate "sample" documents circulated to DISPATCH March 2011 BOF at IETF Prague April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents May 2011 Functionality to include and main alternative protocols identified July 2011 IETF meeting Aug 2011 Draft with text reflecting agreement of what the protocol set should be Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced Dec 2011 Protocol set specification to IESG April 2012 API mapping document to IESG From harald@alvestrand.no Thu Jan 6 03:53:02 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D283A6F01 for ; Thu, 6 Jan 2011 03:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsUzyrXWuSRS for ; Thu, 6 Jan 2011 03:53:00 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id BA7BE3A6EFF for ; Thu, 6 Jan 2011 03:52:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5649339E0FA; Thu, 6 Jan 2011 12:54:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odQ4ItGU8LRw; Thu, 6 Jan 2011 12:54:40 +0100 (CET) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 09DEE39E074; Thu, 6 Jan 2011 12:54:40 +0100 (CET) Message-ID: <4D25AD97.8090201@alvestrand.no> Date: Thu, 06 Jan 2011 12:55:03 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "'dispatch@ietf.org'" Content-Type: multipart/mixed; boundary="------------030804080503010502010802" Cc: "rtc-web@alvestrand.no" Subject: [dispatch] For information: The W3C charter of the RTC-Web related activity there X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 11:53:02 -0000 This is a multi-part message in MIME format. --------------030804080503010502010802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Enclosed is the (HTML format) current proposal for a W3C activity. Discussion of this is not a DISPATCH activity, so should go to the rtc-web list until further notice. Harald --------------030804080503010502010802 Content-Type: text/html; name="webrtc-charter.html" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="webrtc-charter.html" [DRAFT] Web Real-Time Communications Working Group Charter

W3C

[DRAFT] Web Real-Time Communications Working Group Charter

Status: this is a draft charter based on ongoing discussions with Harald Alvestrand, following up on the RTC Web Workshop in October 2010.

The mission of the Web Real-Time Communications Working Group, part of the Rich Web Client Activity, is to define client-side APIs to enable Real Time Communications in Web browsers.

These APIs should enable building applications that can be run inside a browser, requiring no extra downloads or plugins, that allow communication between parties using audio, video and supplementary real-time communication, without having to use intervening servers (unless needed for firewall traversal, or for providing intermediary services).

Join the Web Real-Time Communications Working Group.

End date31 February 2013
ConfidentialityProceedings are public
Initial ChairsCHAIR INFO
Initial Team Contacts
(FTE %: 10)		TEAM CONTACT INFO
Usual Meeting ScheduleTeleconferences: Weekly
Face-to-face: 3-4 per year

Scope

Enabling real-time communications between Web browsers require the following client-side technologies to be available:

  • Device discovery and capability exploration (currently in scope for the Device APIs & Policy Working Group)
  • Capture of media from local devices (camera and microphone) (currently in scope for the Device APIs & Policy Working Group)
  • Encoding and other processing of those media streams,
  • Establishing direct peer-to-peer connections, including firewall/NAT traversal
  • Decoding and processing (including echo cancelling, stream synchronization and a number of other functions) of those streams at the incoming end,
  • Delivery to the user of those media streams via local screens and audio output devices (partially covered with HTML5)

Success Criteria

To advance to Proposed Recommendation, each specification is expected to have two independent implementations of each feature defined in the specification.

To advance to Proposed Recommendation, interoperability between the independent implementations (that is, bidirectional audio and video communication between the implementations) should be demonstrated.

Out of Scope

The definition of the network protocols used to establish the connections between peers is out of scope for this group; in general, it is expected that protocols considerations will be handled in the IETF.

The definition of codecs for audio and video is out of scope.

Deliverables

Recommendation-Track Deliverables

The working group will deliver at least the following specifications, unless they are found to be fully specified within other working groups' finished results:

Media Stream API
An API to manipulate media streams, connecting various processing functions to each other, and to media devices and network connections, including media manipulation functions for e.g. allowing to synchronize streams
Audio Stream API
An extension of the stream API to process audio streams, to enable features such as automatic gain control, mute functions and echo cancellation.
Video Stream API
An extension of the stream API to process video streams, to enable features such as bandwidth limiting, image manipulation or "video mute"
Functional Component API
An API that allows to query for the components present in an implementation, instantiate them, and connect them to media streams.
P2P Connection API
An API to establish peer-to-peer connections between Web browsers
Profile
A minimum profile to which complete implementations should adhere, including standard components that must be available, codecs that need to be supported, and network protoocols that can be connected to.

The specified APIs and the requirements on their implementation must offer functionality that ensures that users' expectations of privacy and control over their devices are met - this includes, but is not limited to, ensuring that users are assured at all times that they know what media they are transmitting, and are able to find out who they are transmitting media to.

Other Deliverables

A comprehensive test suite for all features of a specification is necessary to ensure the specification's robustness, consistency, and implementability, and to promote interoperability between User Agents. Therefore, each specification must have a companion test suite, which should be completed by the end of the Last Call phase, and must be completed, with an implementation report, before transition from Candidate Recommendation to Proposed Recommendation. Additional tests may be added to the test suite at any stage of the Recommendation track, and the maintenance of a implementation report is encouraged.

Other non-normative documents may be created such as:

  • Primers
  • Requirements and use case document for specifications.
  • Non-normative group notes

Given sufficient resources, this Working Group should review other working groups' deliverables that are identified as being relevant to the Working Group's mission.

Milestones

Note: The actual production of some of the deliverables may follow a different timeline. The group will document any schedule changes on the group home page.

@@@

Dependencies and Liaisons

W3C Groups

HTML Working Group
The HTML Working Group defines a number of markup elements and APIs that serves as the basis on which the RTC APIs will be developed; in particular, the outcome of this group might require extensions to the <audio> and <video> tags
Web Applications Working Group
Some of the Web Applications Working Group APIs (such as the Web Sockets API) are likely to serve as inspiration or starting points for the APIs developed by the RTC Working Group.
Device APIs & Policy Working Group
The DAP Working Group on Media Capture APIs will require coordination across the two groups.
Web Notifications Working Group
The abilty of notifying users of incoming communications made possible by the work in the Web Notifications Working Group will be critical to the deployment of Web Real Time Communications.
Audio Incubator Group
The API under development in the Audio Incubator Group is relevant to the expected work on an Audio Stream API
WAI Protocols and Formats Working Group
Reviews from the WAI PF Working Group will be required to ensure the APIs allow to create an accessible user experience.

External Groups

@@@ IETF group on related protocol
The RTC APIs developed by this group will build upon the protocols and formats developed in the IETF @@@ Working Group.
IETF CODEC group
One possible audio codec for use with this API is the one being developed in the IETF.

Participation

To be successful, the Web Real-Time Communications Working Group is expected to have 10 or more active participants for its duration. Effective participation to Web Real-Time Communications Working Group is expected to consume one work day per week for each participant; two days per week for editors. The Web Real-Time Communications Working Group will allocate also the necessary resources for building Test Suites for each specification.

Participants are reminded of the Good Standing requirements of the W3C Process.

Communication

This group primarily conducts its work on the public mailing list LIST NAME. Provide information about additional Member-only lists that are used for administrative purposes.

Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Web Real-Time Communications Working Group home page.

Decision Policy

As explained in the Process Document (section 3.3), this group will seek to make decisions when there is consensus. When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should record a decision (possibly after a formal vote) and any objections, and move on.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.

About this Charter

This charter for the Web Real-Time Communications Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Dominique Hazaël-Massieux, based on initial input from Harald Alvestrand

Copyright© 2010 W3C ® (MIT , ERCIM , Keio), All Rights Reserved.

$Date: 2011-01-06 11:52:39 $

--------------030804080503010502010802-- From harald@alvestrand.no Thu Jan 6 03:55:34 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB523A6F00 for ; Thu, 6 Jan 2011 03:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NwH8e7lXi7a for ; Thu, 6 Jan 2011 03:55:33 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id A04D13A6EFE for ; Thu, 6 Jan 2011 03:55:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3AC2E39E0FA; Thu, 6 Jan 2011 12:57:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43qdMXmCjmzG; Thu, 6 Jan 2011 12:57:15 +0100 (CET) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 92CD939E074; Thu, 6 Jan 2011 12:57:15 +0100 (CET) Message-ID: <4D25AE32.1020205@alvestrand.no> Date: Thu, 06 Jan 2011 12:57:38 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "'dispatch@ietf.org'" , "rtc-web@alvestrand.no" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dispatch] Name discussion: What is the name of the WG that does the RTC-Web stuff? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 11:55:35 -0000 This activity remains nameless. The requirements for a name are: - It should be cute - It should be easy to remember - It should be easy to associate with the activity If it's also somewhat meaningful, that's a nice benefit. The boring choices include: - RTCWEB - WEBRTC There are many others out there. I'll try to keep track of suggestions on a page at the RTCWeb website (rtc-web.alvestrand.no), and we'll find a way to decide after a few suggestions have been made. Let the creativity flow! Harald From tme@americafree.tv Thu Jan 6 04:46:59 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EAF3A6ED4 for ; Thu, 6 Jan 2011 04:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.195 X-Spam-Level: X-Spam-Status: No, score=-102.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivc8r7Muwbbe for ; Thu, 6 Jan 2011 04:46:58 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id BD8B33A6BE4 for ; Thu, 6 Jan 2011 04:46:57 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 1F5499967AC8; Thu, 6 Jan 2011 07:49:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <4D25AD41.7060306@alvestrand.no> Date: Thu, 6 Jan 2011 07:49:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9AFF6B7A-11DF-4111-B0E7-D4BE6C454944@americafree.tv> References: <4D25AD41.7060306@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1081) Cc: "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 12:46:59 -0000 On Jan 6, 2011, at 6:53 AM, Harald Alvestrand wrote: > This is the first of 3 messages going to the DISPATCH list (in the = hope of keeping discussions somewhat organized). >=20 > This is the draft of a charter for an IETF working group to consider = the subject area of "Real time communication in the Web browser = platform". This is one of a paired set of activities, the other one = being a W3C activity (either within an existing WG or in a new WG) that = defines APIs to this functionality. >=20 > The two other messages will contain the W3C proposed charter and a = kickoff for what's usually the most distracting topic in any such = discussion: The name of the group. Dear Harold; Just to be clear, your intent is to have simultaneously a W3C WG and an = IETF WG on this issue ?=20 Shouldn't there be some text about coordination between these efforts ? = I don't see much discussion in either=20 charter as to which is gating, but it seems to me that the W3C work = would have to be gated on the IETF work. Isn't there a danger that the W3C WG might start building on early solutions discussed in the = IETF, only to have the IETF WG decide to go in a different direction ?=20= Regards Marshall > Without further ado: >=20 > ------------------------------------- >=20 > Version: 2 >=20 > Possible Names: > >=20 > Body: >=20 > Many implementations have been made that use a Web browser to support = interactive communications directly between users including voice, = video, collaboration and gaming, but until now, such applications have = required the installation of nonstandard plugins and browser extensions. = There is a desire to standardize such functionality, so that this type = of application can be run in any compatible browser. >=20 > Traditionally, the W3C has defined API and markup languages such as = HTML that work in conjunction with with the IETF over the wire protocols = such as HTTP to allow web browsers to display media that does not have = real time interactive constraints with another human. >=20 > The W3C and IETF plan to collaborate together in their traditional way = to meet the evolving needs of browsers. Specifically the IETF will = provide a set of on the wire protocols, including RTP, to meet the needs = on interactive communications, and the W3C will define the API and = markup to allow web application developers to control the on the wire = protocols. This will allow application developers to write applications = that run in a browser and facilitate interactive communications between = users for voice and video communications, collaboration, and gaming. >=20 > This working group will select and define a minimal set of protocols = that will enable browsers to: >=20 > * have interactive real time voice and video between users using RTP > * interoperate with compatible voice and video systems that are not = web based > * support direct flows of non RTP application data between browsers = for collaboration and gaming applications >=20 > Fortunately very little development of new protocol at IETF is = required for this, only selection of existing protocols and selection of = minimum capabilities to ensure interoperability. The following protocols = are candidates for including in the profile set: >=20 > 1) RTP/ RTCP >=20 > 2) a baseline audio codec for high quality interactive audio. Opus > will be considered as one of the candidates >=20 > 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC > will be considered >=20 > 4) a baseline video codec. H.264 and VP8 will be considered >=20 > 5) Diffserv based QoS >=20 > 6) NAT traversal using ICE >=20 > 7) RFC 4833 based DTMF transport >=20 > 8) RFC 4574 based Label support for identifying streams purpose >=20 > 9) Secure RTP and keying >=20 > 10) support for IPv4, IPv6 and dual stack browsers >=20 > The working group will cooperate closely with the W3C activity that = specifies a semantic level API that allows the control and manipulation = of all the functionality above. In addition, the API needs to = communicate state information and events about what is happening in the = browser that to applications running in the browser. These events and = state need to include information such as: receiving RFC 4833 DTMF, RTP = and RTCP statistics, state of DTLS/SRTP, and signalling state. >=20 > The following topics will be out of scope for the initial phase of the = WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST, = Geolocation, IM & Presence, NSIS, Resource Priority, >=20 > Milestones: >=20 > February 2011 Candidate "sample" documents circulated to DISPATCH >=20 > March 2011 BOF at IETF Prague >=20 > April 2011 WG charter approved by IESG. Chosen document sets adopted = as WG documents >=20 > May 2011 Functionality to include and main alternative protocols = identified >=20 > July 2011 IETF meeting >=20 > Aug 2011 Draft with text reflecting agreement of what the protocol set = should be >=20 > Nov 2010 Documentation specifying mapping of protocol functionality to = W3C-specified API produced >=20 > Dec 2011 Protocol set specification to IESG >=20 > April 2012 API mapping document to IESG >=20 > _______________________________________________ > RTC-Web mailing list > RTC-Web@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/rtc-web >=20 From harald@alvestrand.no Thu Jan 6 05:46:04 2011 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128BB3A6F15 for ; Thu, 6 Jan 2011 05:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOKpE1yNaZFT for ; Thu, 6 Jan 2011 05:46:02 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id BFE753A6F0E for ; Thu, 6 Jan 2011 05:46:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5607739E113; Thu, 6 Jan 2011 14:47:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO9c+z1onQsR; Thu, 6 Jan 2011 14:47:43 +0100 (CET) Received: from [192.168.1.16] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BD32739E074; Thu, 6 Jan 2011 14:47:42 +0100 (CET) Message-ID: <4D25C816.9010204@alvestrand.no> Date: Thu, 06 Jan 2011 14:48:06 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marshall Eubanks References: <4D25AD41.7060306@alvestrand.no> <9AFF6B7A-11DF-4111-B0E7-D4BE6C454944@americafree.tv> In-Reply-To: <9AFF6B7A-11DF-4111-B0E7-D4BE6C454944@americafree.tv> Content-Type: multipart/alternative; boundary="------------040207070909050908000606" Cc: "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 13:46:04 -0000 This is a multi-part message in MIME format. --------------040207070909050908000606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/06/2011 01:49 PM, Marshall Eubanks wrote: > On Jan 6, 2011, at 6:53 AM, Harald Alvestrand wrote: > >> This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized). >> >> This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality. >> >> The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. > Dear Harold; > > Just to be clear, your intent is to have simultaneously a W3C WG and an IETF WG on this issue ? > > Shouldn't there be some text about coordination between these efforts ? I don't see much discussion in either > charter as to which is gating, but it seems to me that the W3C work would have to be gated on the IETF work. Isn't there a danger that > the W3C WG might start building on early solutions discussed in the IETF, only to have the IETF WG decide to go in a different direction ? If either effort fails, we don't have an usable result, so that is indeed very key. As proposed, I think the IETF work gates the W3C work. The IETF charter says: The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. The W3C charter says: External Groups @@@ IETF group on related protocol The RTC APIs developed by this group will build upon the protocols and formats developed in the IETF @@@ Working Group. What more words would you suggest we put in? Finding enough people who have the time to run back and forth between them is a key activity; I for one am allocated to this effort, so I'll be running. Harald > Regards > Marshall > > >> Without further ado: >> >> ------------------------------------- >> >> Version: 2 >> >> Possible Names: >> >> >> Body: >> >> Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser. >> >> Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human. >> >> The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming. >> >> This working group will select and define a minimal set of protocols that will enable browsers to: >> >> * have interactive real time voice and video between users using RTP >> * interoperate with compatible voice and video systems that are not web based >> * support direct flows of non RTP application data between browsers for collaboration and gaming applications >> >> Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set: >> >> 1) RTP/ RTCP >> >> 2) a baseline audio codec for high quality interactive audio. Opus >> will be considered as one of the candidates >> >> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC >> will be considered >> >> 4) a baseline video codec. H.264 and VP8 will be considered >> >> 5) Diffserv based QoS >> >> 6) NAT traversal using ICE >> >> 7) RFC 4833 based DTMF transport >> >> 8) RFC 4574 based Label support for identifying streams purpose >> >> 9) Secure RTP and keying >> >> 10) support for IPv4, IPv6 and dual stack browsers >> >> The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state. >> >> The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocation, IM& Presence, NSIS, Resource Priority, >> >> Milestones: >> >> February 2011 Candidate "sample" documents circulated to DISPATCH >> >> March 2011 BOF at IETF Prague >> >> April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents >> >> May 2011 Functionality to include and main alternative protocols identified >> >> July 2011 IETF meeting >> >> Aug 2011 Draft with text reflecting agreement of what the protocol set should be >> >> Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced >> >> Dec 2011 Protocol set specification to IESG >> >> April 2012 API mapping document to IESG >> >> _______________________________________________ >> RTC-Web mailing list >> RTC-Web@alvestrand.no >> http://www.alvestrand.no/mailman/listinfo/rtc-web >> > --------------040207070909050908000606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/06/2011 01:49 PM, Marshall Eubanks wrote: 
On Jan 6, 2011, at 6:53 AM, Harald Alvestrand wrote:


This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).

This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.

The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group.

Dear Harold;

Just to be clear, your intent is to have simultaneously a W3C WG and an IETF WG on this issue ? 

Shouldn't there be some text about coordination between these efforts ? I don't see much discussion in either 
charter as to which is gating, but it seems to me that the W3C work would have to be gated on the IETF work. Isn't there a danger that
the W3C WG might start building on early solutions discussed in the IETF, only to have the IETF WG decide to go in a different direction ?
If either effort fails, we don't have an usable result, so that is indeed very key. As proposed, I think the IETF work gates the W3C work.

The IETF charter says:

The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above.

The W3C charter says:

External Groups

@@@ IETF group on related protocol
The RTC APIs developed by this group will build upon the protocols and formats developed in the IETF @@@ Working Group.
What more words would you suggest we put in?

Finding enough people who have the time to run back and forth between them is a key activity; I for one am allocated to this effort, so I'll be running.

                     Harald

    

    

      
Regards
Marshall




      

        
Without further ado:

-------------------------------------

Version: 2

Possible Names:
<This space deliberately left blank for later discussion>

Body:

Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible browser.

Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.

The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers  to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.

This working group will select and define a minimal set of protocols that will enable browsers to:

* have interactive real time voice and video between users using RTP
* interoperate with compatible voice and video systems that are not web based
* support direct flows of non RTP application data between browsers for collaboration and gaming applications

Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:

1) RTP/ RTCP

2) a baseline audio codec for high quality interactive audio. Opus
will be considered as one of the candidates

3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
will be considered

4) a baseline video codec. H.264 and VP8 will be considered

5) Diffserv based QoS

6) NAT traversal using ICE

7) RFC 4833 based DTMF transport

8) RFC 4574 based Label support for identifying streams purpose

9) Secure RTP and keying

10) support for IPv4, IPv6 and dual stack browsers

The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP,  and signalling state.

The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocation, IM & Presence, NSIS, Resource Priority,

Milestones:

February 2011 Candidate "sample" documents circulated to DISPATCH

March 2011 BOF at IETF Prague

April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents

May 2011 Functionality to include and main alternative protocols identified

July 2011 IETF meeting

Aug 2011 Draft with text reflecting agreement of what the protocol set should be

Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced

Dec 2011 Protocol set specification to IESG

April 2012 API mapping document to IESG

_______________________________________________
RTC-Web mailing list
RTC-Web@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web



      

      



    

    

  


--------------040207070909050908000606--

From keith.drage@alcatel-lucent.com  Thu Jan  6 05:50:49 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC7C3A6E28 for ; Thu,  6 Jan 2011 05:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.636
X-Spam-Level: 
X-Spam-Status: No, score=-103.636 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awIRSA4M5RCL for ; Thu,  6 Jan 2011 05:50:47 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 870793A6F0E for ; Thu,  6 Jan 2011 05:50:47 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p06DqoIc025423 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Jan 2011 14:52:51 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 6 Jan 2011 14:52:50 +0100
From: "DRAGE, Keith (Keith)" 
To: Harald Alvestrand , "'dispatch@ietf.org'" 
Date: Thu, 6 Jan 2011 14:52:50 +0100
Thread-Topic: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
Thread-Index: AcutmHfIRSgjTrCzQySoCS9o1jLggAADplpA
Message-ID: 
References: <4D25AD41.7060306@alvestrand.no>
In-Reply-To: <4D25AD41.7060306@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84
Cc: "rtc-web@alvestrand.no" 
Subject: Re: [dispatch] Charter proposal: The activity hitherto known as	"RTC-WEB at IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 13:50:49 -0000

Nowhere have you specified in the milestones what status the intended deliv=
erables are.

Assuming the profile is intended to be proposed standard, then presumably y=
ou need to ensure all the constituent parts are of proposed standard, or so=
me equivalent referenceable standard in some other organisation.

Opus does not yet have a RTP payload format, although I understand one is p=
lanned, no drafts exist at the moment.

iLBC is defined as an experimental RFC - does it need to be upgraded to sta=
ndards track or is there some other reference.

VP8 has no RTP payload format defined, unless it is masquerading under some=
 other name.

Presumably you need a paragraph in the charter relating to working with oth=
er groups (in particular IETF WG) to ensure that profiled specifications ex=
ist and are brought to standards track level.

regards


Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand
> Sent: Thursday, January 06, 2011 11:54 AM
> To: 'dispatch@ietf.org'
> Cc: rtc-web@alvestrand.no
> Subject: [dispatch] Charter proposal: The activity hitherto=20
> known as "RTC-WEB at IETF"
>=20
> This is the first of 3 messages going to the DISPATCH list=20
> (in the hope of keeping discussions somewhat organized).
>=20
> This is the draft of a charter for an IETF working group to=20
> consider the subject area of "Real time communication in the=20
> Web browser platform".=20
> This is one of a paired set of activities, the other one=20
> being a W3C activity (either within an existing WG or in a=20
> new WG) that defines APIs to this functionality.
>=20
> The two other messages will contain the W3C proposed charter=20
> and a kickoff for what's usually the most distracting topic=20
> in any such
> discussion: The name of the group.
> Without further ado:
>=20
> -------------------------------------
>=20
> Version: 2
>=20
> Possible Names:
> 
>=20
> Body:
>=20
> Many implementations have been made that use a Web browser to=20
> support interactive communications directly between users=20
> including voice, video, collaboration and gaming, but until=20
> now, such applications have required the installation of=20
> nonstandard plugins and browser extensions.=20
> There is a desire to standardize such functionality, so that=20
> this type of application can be run in any compatible browser.
>=20
> Traditionally, the W3C has defined API and markup languages=20
> such as HTML that work in conjunction with with the IETF over=20
> the wire protocols such as HTTP to allow web browsers to=20
> display media that does not have real time interactive=20
> constraints with another human.
>=20
> The W3C and IETF plan to collaborate together in their=20
> traditional way to meet the evolving needs of browsers.=20
> Specifically the IETF will provide a set of on the wire=20
> protocols, including RTP, to meet the needs on interactive=20
> communications, and the W3C will define the API and markup to=20
> allow web application developers to control the on the wire=20
> protocols. This will allow application developers  to write=20
> applications that run in a browser and facilitate interactive=20
> communications between users for voice and video=20
> communications, collaboration, and gaming.
>=20
> This working group will select and define a minimal set of=20
> protocols that will enable browsers to:
>=20
> * have interactive real time voice and video between users using RTP
> * interoperate with compatible voice and video systems that=20
> are not web based
> * support direct flows of non RTP application data between=20
> browsers for collaboration and gaming applications
>=20
> Fortunately very little development of new protocol at IETF=20
> is required for this, only selection of existing protocols=20
> and selection of minimum capabilities to ensure=20
> interoperability. The following protocols are candidates for=20
> including in the profile set:
>=20
> 1) RTP/ RTCP
>=20
> 2) a baseline audio codec for high quality interactive audio.=20
> Opus will be considered as one of the candidates
>=20
> 3) a baseline audio codec for PSTN interoperability. G.711=20
> and iLBC will be considered
>=20
> 4) a baseline video codec. H.264 and VP8 will be considered
>=20
> 5) Diffserv based QoS
>=20
> 6) NAT traversal using ICE
>=20
> 7) RFC 4833 based DTMF transport
>=20
> 8) RFC 4574 based Label support for identifying streams purpose
>=20
> 9) Secure RTP and keying
>=20
> 10) support for IPv4, IPv6 and dual stack browsers
>=20
> The working group will cooperate closely with the W3C=20
> activity that specifies a semantic level API that allows the=20
> control and manipulation of all the functionality above. In=20
> addition, the API needs to communicate state information and=20
> events about what is happening in the browser that to=20
> applications running in the browser. These events and state=20
> need to include information such as: receiving RFC 4833 DTMF,=20
> RTP and RTCP statistics, state of DTLS/SRTP,  and signalling state.
>=20
> The following topics will be out of scope for the initial=20
> phase of the WG but could be added after a recharter: RTSP,=20
> RSVP, NSIS, LOST, Geolocation, IM & Presence, NSIS, Resource Priority,
>=20
> Milestones:
>=20
> February 2011 Candidate "sample" documents circulated to DISPATCH
>=20
> March 2011 BOF at IETF Prague
>=20
> April 2011 WG charter approved by IESG. Chosen document sets=20
> adopted as WG documents
>=20
> May 2011 Functionality to include and main alternative=20
> protocols identified
>=20
> July 2011 IETF meeting
>=20
> Aug 2011 Draft with text reflecting agreement of what the=20
> protocol set should be
>=20
> Nov 2010 Documentation specifying mapping of protocol=20
> functionality to W3C-specified API produced
>=20
> Dec 2011 Protocol set specification to IESG
>=20
> April 2012 API mapping document to IESG
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> =

From keith.drage@alcatel-lucent.com  Thu Jan  6 05:50:49 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2873A6F0E for ; Thu,  6 Jan 2011 05:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.629
X-Spam-Level: 
X-Spam-Status: No, score=-105.629 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0mlK6QbjEAv for ; Thu,  6 Jan 2011 05:50:47 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 884353A6F0F for ; Thu,  6 Jan 2011 05:50:47 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p06DqpQB011099 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Jan 2011 14:52:52 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 6 Jan 2011 14:52:52 +0100
From: "DRAGE, Keith (Keith)" 
To: Harald Alvestrand , "'dispatch@ietf.org'" , "rtc-web@alvestrand.no" 
Date: Thu, 6 Jan 2011 14:49:30 +0100
Thread-Topic: [dispatch] Name discussion: What is the name of the WG that does the RTC-Web stuff?
Thread-Index: AcutmPCXslHC3aTNRvCeVPcmAv/52QAD01aA
Message-ID: 
References: <4D25AE32.1020205@alvestrand.no>
In-Reply-To: <4D25AE32.1020205@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83
Subject: Re: [dispatch] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 13:50:49 -0000

Please stick to boring.

I have the greatest difficulty in remembering what some current RAI WG are =
about when starting from the acronym.

So I would place your requirements in reverse order for a prioritised list.

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand
> Sent: Thursday, January 06, 2011 11:58 AM
> To: 'dispatch@ietf.org'; rtc-web@alvestrand.no
> Subject: [dispatch] Name discussion: What is the name of the=20
> WG that does the RTC-Web stuff?
>=20
> This activity remains nameless.
> The requirements for a name are:
>=20
> - It should be cute
> - It should be easy to remember
> - It should be easy to associate with the activity
>=20
> If it's also somewhat meaningful, that's a nice benefit.
> The boring choices include:
>=20
> - RTCWEB
> - WEBRTC
>=20
> There are many others out there. I'll try to keep track of=20
> suggestions on a page at the RTCWeb website=20
> (rtc-web.alvestrand.no), and we'll find a way to decide after=20
> a few suggestions have been made.
> Let the creativity flow!
>=20
>                Harald
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> =

From peter.musgrave@magorcorp.com  Thu Jan  6 06:13:32 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5453A6F11 for ; Thu,  6 Jan 2011 06:13:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.912
X-Spam-Level: 
X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXiSnqkglgN5 for ; Thu,  6 Jan 2011 06:13:31 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 590F33A6D3C for ; Thu,  6 Jan 2011 06:13:31 -0800 (PST)
Received: by iyi42 with SMTP id 42so16216083iyi.31 for ; Thu, 06 Jan 2011 06:15:38 -0800 (PST)
Received: by 10.42.218.66 with SMTP id hp2mr15118799icb.244.1294323338136; Thu, 06 Jan 2011 06:15:38 -0800 (PST)
Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id u5sm20534759ics.18.2011.01.06.06.15.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 06:15:36 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Peter Musgrave 
In-Reply-To: 
Date: Thu, 6 Jan 2011 09:15:34 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4D25AE32.1020205@alvestrand.no> 
To: "DRAGE, Keith (Keith)" 
X-Mailer: Apple Mail (2.1082)
Cc: "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" 
Subject: Re: [dispatch] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 14:13:32 -0000

Here, here.=20

Let's just pick rtcweb (since that what has been used so far) and spare =
mail buffers all over the planet....

Peter

On 2011-01-06, at 8:49 AM, DRAGE, Keith (Keith) wrote:

> Please stick to boring.
>=20
> I have the greatest difficulty in remembering what some current RAI WG =
are about when starting from the acronym.
>=20
> So I would place your requirements in reverse order for a prioritised =
list.
>=20
> Keith
>=20
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org=20
>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand
>> Sent: Thursday, January 06, 2011 11:58 AM
>> To: 'dispatch@ietf.org'; rtc-web@alvestrand.no
>> Subject: [dispatch] Name discussion: What is the name of the=20
>> WG that does the RTC-Web stuff?
>>=20
>> This activity remains nameless.
>> The requirements for a name are:
>>=20
>> - It should be cute
>> - It should be easy to remember
>> - It should be easy to associate with the activity
>>=20
>> If it's also somewhat meaningful, that's a nice benefit.
>> The boring choices include:
>>=20
>> - RTCWEB
>> - WEBRTC
>>=20
>> There are many others out there. I'll try to keep track of=20
>> suggestions on a page at the RTCWeb website=20
>> (rtc-web.alvestrand.no), and we'll find a way to decide after=20
>> a few suggestions have been made.
>> Let the creativity flow!
>>=20
>>               Harald
>>=20
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From harald@alvestrand.no  Thu Jan  6 07:36:32 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A86593A6C4F for ; Thu,  6 Jan 2011 07:36:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level: 
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAvZGv+YXn9U for ; Thu,  6 Jan 2011 07:36:31 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 500033A6C33 for ; Thu,  6 Jan 2011 07:36:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BFE1039E119; Thu,  6 Jan 2011 16:38:13 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa-NdcFm3pVn; Thu,  6 Jan 2011 16:38:13 +0100 (CET)
Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4B79739E074; Thu,  6 Jan 2011 16:38:10 +0100 (CET)
Message-ID: <4D25E1F8.2000802@alvestrand.no>
Date: Thu, 06 Jan 2011 16:38:32 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: Justin Uberti 
References:  <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com>   <4D201584.9040007@alvestrand.no> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020201020402090200080800"
Cc: rtc-web@alvestrand.no, dispatch@ietf.org, Markus.Isomaki@nokia.com
Subject: Re: [dispatch] [RTW] Comments on draft-alvestrand-dispatch-rtcweb-datagram
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 15:36:32 -0000

This is a multi-part message in MIME format.
--------------020201020402090200080800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 01/06/11 08:05, Justin Uberti wrote:
>
>
>     Background: I had a discussion with a coworker who wanted to have
>     a single API to both streaming and datagram service; I believe it
>     makes more sense to define an API to a datagram service and an API
>     to a streaming service separately - the big argument for PseudoTCP
>     is the client-to-client connection case, where one often finds
>     that UDP works and TCP doesn't.
>
>
> I had been thinking the datagram and streaming services should use a 
> single API - much of the API ends up being the same, and that's how 
> BSD sockets work. There are a few differences for streaming services, 
> but they are mostly (entirely?) additive (flow control being the main 
> one).

The huge difference is that a streaming API gives you a sequence of 
bytes, in strict order, while a datagram API gives you a (not 
necessarily ordered) sequence of datagrams. Each datagram is guaranteed 
to be treated as an unit, but order is not preserved. There is no 
guarantee about block boundaries in a stream (you have to create them 
yourself if you want them), but order is strictly preserved.

For most of the rest of the functions, the APIs can (and should) be the 
same, but the sending and reception of data is different.

                       Harald



--------------020201020402090200080800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit



  
    
  
  
    On 01/06/11 08:05, Justin Uberti wrote:

    

      

        

          

          Background: I had a discussion with a coworker who wanted to
          have a single API to both streaming and datagram service; I
          believe it makes more sense to define an API to a datagram
          service and an API to a streaming service separately - the big
          argument for PseudoTCP is the client-to-client connection
          case, where one often finds that UDP works and TCP doesn't.

        

        


        

        
I had been thinking the datagram and streaming services
          should use a single API - much of the API ends up being the
          same, and that's how BSD sockets work. There are a few
          differences for streaming services, but they are mostly
          (entirely?) additive (flow control being the main one).

        

      

    

    

    The huge difference is that a streaming API gives you a sequence of
    bytes, in strict order, while a datagram API gives you a (not
    necessarily ordered) sequence of datagrams. Each datagram is
    guaranteed to be treated as an unit, but order is not preserved.
    There is no guarantee about block boundaries in a stream (you have
    to create them yourself if you want them), but order is strictly
    preserved.

    

    For most of the rest of the functions, the APIs can (and should) be
    the same, but the sending and reception of data is different.

    

                          Harald

    

    

  


--------------020201020402090200080800--

From tme@americafree.tv  Thu Jan  6 08:40:19 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 982643A6C4F for ; Thu,  6 Jan 2011 08:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.197
X-Spam-Level: 
X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u529z0vuAjJw for ; Thu,  6 Jan 2011 08:40:18 -0800 (PST)
Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C4BB43A6C9E for ; Thu,  6 Jan 2011 08:40:17 -0800 (PST)
Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id AA438996D9BF; Thu,  6 Jan 2011 11:42:22 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Marshall Eubanks 
In-Reply-To: <4D25C816.9010204@alvestrand.no>
Date: Thu, 6 Jan 2011 11:42:19 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4D25AD41.7060306@alvestrand.no> <9AFF6B7A-11DF-4111-B0E7-D4BE6C454944@americafree.tv> <4D25C816.9010204@alvestrand.no>
To: Harald Alvestrand 
X-Mailer: Apple Mail (2.1081)
Cc: "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" 
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 16:40:19 -0000

On Jan 6, 2011, at 8:48 AM, Harald Alvestrand wrote:

> On 01/06/2011 01:49 PM, Marshall Eubanks wrote:
>> On Jan 6, 2011, at 6:53 AM, Harald Alvestrand wrote:
>>=20
>>=20
>>> This is the first of 3 messages going to the DISPATCH list (in the =
hope of keeping discussions somewhat organized).
>>>=20
>>> This is the draft of a charter for an IETF working group to consider =
the subject area of "Real time communication in the Web browser =
platform". This is one of a paired set of activities, the other one =
being a W3C activity (either within an existing WG or in a new WG) that =
defines APIs to this functionality.
>>>=20
>>> The two other messages will contain the W3C proposed charter and a =
kickoff for what's usually the most distracting topic in any such =
discussion: The name of the group.
>>>=20
>> Dear Harold;
>>=20
>> Just to be clear, your intent is to have simultaneously a W3C WG and =
an IETF WG on this issue ?=20
>>=20
>> Shouldn't there be some text about coordination between these efforts =
? I don't see much discussion in either=20
>> charter as to which is gating, but it seems to me that the W3C work =
would have to be gated on the IETF work. Isn't there a danger that
>> the W3C WG might start building on early solutions discussed in the =
IETF, only to have the IETF WG decide to go in a different direction ?=20=

>>=20
> If either effort fails, we don't have an usable result, so that is =
indeed very key. As proposed, I think the IETF work gates the W3C work.
>=20
> The IETF charter says:
>=20
> The working group will cooperate closely with the W3C activity that =
specifies a semantic level API that allows the control and manipulation =
of all the functionality above.
>=20
> The W3C charter says:
>=20
>=20
> External Groups
>=20
> @@@ IETF group on related protocol
> The RTC APIs developed by this group will build upon the protocols and =
formats developed in the IETF @@@ Working Group.

s/Group./Group and will not be finalized until that work is published./

(Of course, to get published you have to go through the IESG, which is =
the real point here. I would myself be satisfied with AUTH48 as
a marker for that.)

> What more words would you suggest we put in?
>=20
> Finding enough people who have the time to run back and forth between =
them is a key activity; I for one am allocated to this effort, so I'll =
be running.
>=20

That is going to be tough, especially as the W3C has "good standing" =
requirements.=20

http://www.w3.org/2005/10/Process-20051014/groups.html#good-standing

which you may lose if "the individual has missed more than one of the =
last three face-to-face meetings" or
"the individual has missed more than one of the last three distributed =
meetings."
=20
So, to be in good standing with the W3C WG I would have to attend 2 out =
of 3 F2F meetings somewhere - are any planned ? =20

It also says

"Effective participation to Web Real-Time Communications Working Group =
is expected to consume one work day per week for each participant; two =
days per week for editors."

I don't know if this is required for "good standing" but taken together =
this is a hit, or could be (there are a lot of "weasel words" in these
two documents.)

Can you provide insight as to how much of a time commitment the W3C =
effort will really be ?

Regards
Marshall

P.S. A nit below.


>                      Harald
>=20
>> Regards
>> Marshall
>>=20
>>=20
>>=20
>>> Without further ado:
>>>=20
>>> -------------------------------------
>>>=20
>>> Version: 2
>>>=20
>>> Possible Names:
>>> 
>>>=20
>>> Body:
>>>=20
>>> Many implementations have been made that use a Web browser to =
support interactive communications directly between users including =
voice, video, collaboration and gaming, but until now, such applications =
have required the installation of nonstandard plugins and browser =
extensions. There is a desire to standardize such functionality, so that =
this type of application can be run in any compatible browser.
>>>=20
>>> Traditionally, the W3C has defined API and markup languages such as =
HTML that work in conjunction with with the IETF over the wire protocols =
such as HTTP to allow web browsers to display media that does not have =
real time interactive constraints with another human.
>>>=20
>>> The W3C and IETF plan to collaborate together in their traditional =
way to meet the evolving needs of browsers. Specifically the IETF will =
provide a set of on the wire protocols, including RTP, to meet the needs =
on interactive communications, and the W3C will define the API and =
markup to allow web application developers to control the on the wire =
protocols. This will allow application developers  to write applications =
that run in a browser and facilitate interactive communications between =
users for voice and video communications, collaboration, and gaming.
>>>=20
>>> This working group will select and define a minimal set of protocols =
that will enable browsers to:
>>>=20
>>> * have interactive real time voice and video between users using RTP
>>> * interoperate with compatible voice and video systems that are not =
web based
>>> * support direct flows of non RTP application data between browsers =
for collaboration and gaming applications
>>>=20
>>> Fortunately very little development of new protocol at IETF is =
required for this, only selection of existing protocols and selection of =
minimum capabilities to ensure interoperability. The following protocols =
are candidates for including in the profile set:
>>>=20
>>> 1) RTP/ RTCP
>>>=20
>>> 2) a baseline audio codec for high quality interactive audio. Opus
>>> will be considered as one of the candidates
>>>=20
>>> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
>>> will be considered
>>>=20
>>> 4) a baseline video codec. H.264 and VP8 will be considered
>>>=20
>>> 5) Diffserv based QoS
>>>=20
>>> 6) NAT traversal using ICE
>>>=20
>>> 7) RFC 4833 based DTMF transport
>>>=20
>>> 8) RFC 4574 based Label support for identifying streams purpose
>>>=20
>>> 9) Secure RTP and keying
>>>=20
>>> 10) support for IPv4, IPv6 and dual stack browsers
>>>=20
>>> The working group will cooperate closely with the W3C activity that =
specifies a semantic level API that allows the control and manipulation =
of all the functionality above. In addition, the API needs to =
communicate state information and events about what is happening in the =
browser that to applications running in the browser. These events and =
state need to include information such as: receiving RFC 4833 DTMF, RTP =
and RTCP statistics, state of DTLS/SRTP,  and signalling state.

s/signalling/signaling/=20

>>>=20
>>> The following topics will be out of scope for the initial phase of =
the WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST, =
Geolocation, IM & Presence, NSIS, Resource Priority,
>>>=20
>>> Milestones:
>>>=20
>>> February 2011 Candidate "sample" documents circulated to DISPATCH
>>>=20
>>> March 2011 BOF at IETF Prague
>>>=20
>>> April 2011 WG charter approved by IESG. Chosen document sets adopted =
as WG documents
>>>=20
>>> May 2011 Functionality to include and main alternative protocols =
identified
>>>=20
>>> July 2011 IETF meeting
>>>=20
>>> Aug 2011 Draft with text reflecting agreement of what the protocol =
set should be
>>>=20
>>> Nov 2010 Documentation specifying mapping of protocol functionality =
to W3C-specified API produced
>>>=20
>>> Dec 2011 Protocol set specification to IESG
>>>=20
>>> April 2012 API mapping document to IESG
>>>=20
>>> _______________________________________________
>>> RTC-Web mailing list
>>>=20
>>> RTC-Web@alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>=20
>>>=20
>>>=20
>>=20
>=20


From tme@americafree.tv  Thu Jan  6 08:46:20 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0108D3A6C9E for ; Thu,  6 Jan 2011 08:46:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.2
X-Spam-Level: 
X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=0.399,  BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOkF+MrS9RSE for ; Thu,  6 Jan 2011 08:46:19 -0800 (PST)
Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id E9D9E3A6C4F for ; Thu,  6 Jan 2011 08:46:18 -0800 (PST)
Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id A784E996DC24; Thu,  6 Jan 2011 11:48:25 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Marshall Eubanks 
In-Reply-To: <4D25AE32.1020205@alvestrand.no>
Date: Thu, 6 Jan 2011 11:47:52 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4D25AE32.1020205@alvestrand.no>
To: Harald Alvestrand 
X-Mailer: Apple Mail (2.1081)
Cc: "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" 
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 16:46:20 -0000

On Jan 6, 2011, at 6:57 AM, Harald Alvestrand wrote:

> This activity remains nameless.
> The requirements for a name are:
>=20
> - It should be cute
> - It should be easy to remember
> - It should be easy to associate with the activity
>=20
> If it's also somewhat meaningful, that's a nice benefit.
> The boring choices include:
>=20
> - RTCWEB
> - WEBRTC

Here is my proposal, not yet used in the IETF :

REALTIME

Marshall

>=20
> There are many others out there. I'll try to keep track of suggestions =
on a page at the RTCWeb website (rtc-web.alvestrand.no), and we'll find =
a way to decide after a few suggestions have been made.
> Let the creativity flow!
>=20
>              Harald
>=20
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>=20


From harald@alvestrand.no  Thu Jan  6 09:05:15 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1FD3A6C9E for ; Thu,  6 Jan 2011 09:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.544
X-Spam-Level: 
X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0s9Phl0Lc7a for ; Thu,  6 Jan 2011 09:05:13 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 818E73A6C9B for ; Thu,  6 Jan 2011 09:05:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CCAB139E12F; Thu,  6 Jan 2011 18:06:55 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsqZnUCkjepG; Thu,  6 Jan 2011 18:06:54 +0100 (CET)
Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4B3AD39E04C; Thu,  6 Jan 2011 18:06:54 +0100 (CET)
Message-ID: <4D25F6C5.4010903@alvestrand.no>
Date: Thu, 06 Jan 2011 18:07:17 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: "DRAGE, Keith (Keith)" 
References: <4D25AD41.7060306@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" 
Subject: Re: [dispatch] Charter proposal: The activity hitherto known as	"RTC-WEB at IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 17:05:15 -0000

On 01/06/11 14:52, DRAGE, Keith (Keith) wrote:
> Nowhere have you specified in the milestones what status the intended deliverables are.
Indeed, there isn't even an explicit list of deliverables. That has to 
be added.
My thinking goes like:

- Profile document (or documents): Proposed Standard
- API mapping document: either Info or Proposed
- Scenarios document (I think we need one): Informational

Thoughts?

> Assuming the profile is intended to be proposed standard, then presumably you need to ensure all the constituent parts are of proposed standard, or some equivalent referenceable standard in some other organisation.
The term I prefer in requirements is "stable reference" - we need to 
know what we refer to.
If we have a standards-track and a non-standards-track spec for the same 
thing, I do think we should most often prefer the standards-track spec, 
but I don't want to be dogmatic about it.
> Opus does not yet have a RTP payload format, although I understand one is planned, no drafts exist at the moment.
Coordination item for the CODEC WG.
> iLBC is defined as an experimental RFC - does it need to be upgraded to standards track or is there some other reference.
>
> VP8 has no RTP payload format defined, unless it is masquerading under some other name.
I know some people have been working on this, but I don't think there is 
a draft yet.
> Presumably you need a paragraph in the charter relating to working with other groups (in particular IETF WG) to ensure that profiled specifications exist and are brought to standards track level.
Yes, definitely.
> regards
>
>
> Keith
>
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org
>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand
>> Sent: Thursday, January 06, 2011 11:54 AM
>> To: 'dispatch@ietf.org'
>> Cc: rtc-web@alvestrand.no
>> Subject: [dispatch] Charter proposal: The activity hitherto
>> known as "RTC-WEB at IETF"
>>
>> This is the first of 3 messages going to the DISPATCH list
>> (in the hope of keeping discussions somewhat organized).
>>
>> This is the draft of a charter for an IETF working group to
>> consider the subject area of "Real time communication in the
>> Web browser platform".
>> This is one of a paired set of activities, the other one
>> being a W3C activity (either within an existing WG or in a
>> new WG) that defines APIs to this functionality.
>>
>> The two other messages will contain the W3C proposed charter
>> and a kickoff for what's usually the most distracting topic
>> in any such
>> discussion: The name of the group.
>> Without further ado:
>>
>> -------------------------------------
>>
>> Version: 2
>>
>> Possible Names:
>> 
>>
>> Body:
>>
>> Many implementations have been made that use a Web browser to
>> support interactive communications directly between users
>> including voice, video, collaboration and gaming, but until
>> now, such applications have required the installation of
>> nonstandard plugins and browser extensions.
>> There is a desire to standardize such functionality, so that
>> this type of application can be run in any compatible browser.
>>
>> Traditionally, the W3C has defined API and markup languages
>> such as HTML that work in conjunction with with the IETF over
>> the wire protocols such as HTTP to allow web browsers to
>> display media that does not have real time interactive
>> constraints with another human.
>>
>> The W3C and IETF plan to collaborate together in their
>> traditional way to meet the evolving needs of browsers.
>> Specifically the IETF will provide a set of on the wire
>> protocols, including RTP, to meet the needs on interactive
>> communications, and the W3C will define the API and markup to
>> allow web application developers to control the on the wire
>> protocols. This will allow application developers  to write
>> applications that run in a browser and facilitate interactive
>> communications between users for voice and video
>> communications, collaboration, and gaming.
>>
>> This working group will select and define a minimal set of
>> protocols that will enable browsers to:
>>
>> * have interactive real time voice and video between users using RTP
>> * interoperate with compatible voice and video systems that
>> are not web based
>> * support direct flows of non RTP application data between
>> browsers for collaboration and gaming applications
>>
>> Fortunately very little development of new protocol at IETF
>> is required for this, only selection of existing protocols
>> and selection of minimum capabilities to ensure
>> interoperability. The following protocols are candidates for
>> including in the profile set:
>>
>> 1) RTP/ RTCP
>>
>> 2) a baseline audio codec for high quality interactive audio.
>> Opus will be considered as one of the candidates
>>
>> 3) a baseline audio codec for PSTN interoperability. G.711
>> and iLBC will be considered
>>
>> 4) a baseline video codec. H.264 and VP8 will be considered
>>
>> 5) Diffserv based QoS
>>
>> 6) NAT traversal using ICE
>>
>> 7) RFC 4833 based DTMF transport
>>
>> 8) RFC 4574 based Label support for identifying streams purpose
>>
>> 9) Secure RTP and keying
>>
>> 10) support for IPv4, IPv6 and dual stack browsers
>>
>> The working group will cooperate closely with the W3C
>> activity that specifies a semantic level API that allows the
>> control and manipulation of all the functionality above. In
>> addition, the API needs to communicate state information and
>> events about what is happening in the browser that to
>> applications running in the browser. These events and state
>> need to include information such as: receiving RFC 4833 DTMF,
>> RTP and RTCP statistics, state of DTLS/SRTP,  and signalling state.
>>
>> The following topics will be out of scope for the initial
>> phase of the WG but could be added after a recharter: RTSP,
>> RSVP, NSIS, LOST, Geolocation, IM&  Presence, NSIS, Resource Priority,
>>
>> Milestones:
>>
>> February 2011 Candidate "sample" documents circulated to DISPATCH
>>
>> March 2011 BOF at IETF Prague
>>
>> April 2011 WG charter approved by IESG. Chosen document sets
>> adopted as WG documents
>>
>> May 2011 Functionality to include and main alternative
>> protocols identified
>>
>> July 2011 IETF meeting
>>
>> Aug 2011 Draft with text reflecting agreement of what the
>> protocol set should be
>>
>> Nov 2010 Documentation specifying mapping of protocol
>> functionality to W3C-specified API produced
>>
>> Dec 2011 Protocol set specification to IESG
>>
>> April 2012 API mapping document to IESG
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>


From keith.drage@alcatel-lucent.com  Thu Jan  6 09:46:49 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EAA83A6CC0 for ; Thu,  6 Jan 2011 09:46:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.619
X-Spam-Level: 
X-Spam-Status: No, score=-105.619 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx4APQrgK4jy for ; Thu,  6 Jan 2011 09:46:48 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id D8DA63A6C9B for ; Thu,  6 Jan 2011 09:46:47 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p06Hmft3009539 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Jan 2011 18:48:52 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 6 Jan 2011 18:48:47 +0100
From: "DRAGE, Keith (Keith)" 
To: Harald Alvestrand 
Date: Thu, 6 Jan 2011 18:48:46 +0100
Thread-Topic: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
Thread-Index: AcutxDNvlR4X3E8bQUO+9gs7CmnqFAAANLrg
Message-ID: 
References: <4D25AD41.7060306@alvestrand.no>  <4D25F6C5.4010903@alvestrand.no>
In-Reply-To: <4D25F6C5.4010903@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83
Cc: "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" 
Subject: Re: [dispatch] Charter proposal: The activity hitherto known as	"RTC-WEB at IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 17:46:49 -0000

> > Assuming the profile is intended to be proposed standard,=20
> then presumably you need to ensure all the constituent parts=20
> are of proposed standard, or some equivalent referenceable=20
> standard in some other organisation.
> The term I prefer in requirements is "stable reference" - we=20
> need to know what we refer to.
> If we have a standards-track and a non-standards-track spec=20
> for the same thing, I do think we should most often prefer=20
> the standards-track spec, but I don't want to be dogmatic about it.

To profile a document to me has a defined meaning, and at least one ISO hav=
e defined, i.e. it takes an existing specification or specifications and st=
ates which requirements apply. Mandatory requirements can only be mandatory=
 in the profile. Option requirements can become mandatory in the profile. R=
FC 2026 seems to use the term "Applicability statement" with much the same =
meaning.

As such, I believe the following applies (quoting from RFC 2026) but this i=
s also my understanding for profile.

   An AS may not have a higher maturity level in the standards track
   than any standards-track TS on which the AS relies (see section 4.1).
   For example, a TS at Draft Standard level may be referenced by an AS
   at the Proposed Standard or Draft Standard level, but not by an AS at
   the Standard level.

So a profile at proposed standard needs to call up proposed standard specif=
ications. I certainly allow us to take equivalent level documents from othe=
r organisations.=20

I agree this is not the most important thing to get the charter resolved, b=
ut it may result in some other IETF groups needing to do a little more work=
 than you expect. The biggest impact would be if iLBC is chosen as that has=
 a codec definition (and payload format) at experimental level (RFC 3951 an=
d RFC 3952). As to why they are experimental, I don't know, but I suspect t=
hat IETF was required to produce a payload definition, and for that it need=
ed a referencerable document for the codec definition, but did not want to =
get involved at that time in standards track activity for the codec itself.=
 (Nowadays that would not be a block to producing a standards track payload=
 type).

In any case, it would seem to send the wrong message to profile something t=
hat is still formally experimental.

No issue with your other responses.

Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand
> Sent: Thursday, January 06, 2011 5:07 PM
> To: DRAGE, Keith (Keith)
> Cc: rtc-web@alvestrand.no; 'dispatch@ietf.org'
> Subject: Re: [dispatch] Charter proposal: The activity=20
> hitherto known as "RTC-WEB at IETF"
>=20
> On 01/06/11 14:52, DRAGE, Keith (Keith) wrote:
> > Nowhere have you specified in the milestones what status=20
> the intended deliverables are.
> Indeed, there isn't even an explicit list of deliverables.=20
> That has to be added.
> My thinking goes like:
>=20
> - Profile document (or documents): Proposed Standard
> - API mapping document: either Info or Proposed
> - Scenarios document (I think we need one): Informational
>=20
> Thoughts?
>=20
> > Assuming the profile is intended to be proposed standard,=20
> then presumably you need to ensure all the constituent parts=20
> are of proposed standard, or some equivalent referenceable=20
> standard in some other organisation.
> The term I prefer in requirements is "stable reference" - we=20
> need to know what we refer to.
> If we have a standards-track and a non-standards-track spec=20
> for the same thing, I do think we should most often prefer=20
> the standards-track spec, but I don't want to be dogmatic about it.
> > Opus does not yet have a RTP payload format, although I=20
> understand one is planned, no drafts exist at the moment.
> Coordination item for the CODEC WG.
> > iLBC is defined as an experimental RFC - does it need to be=20
> upgraded to standards track or is there some other reference.
> >
> > VP8 has no RTP payload format defined, unless it is=20
> masquerading under some other name.
> I know some people have been working on this, but I don't=20
> think there is a draft yet.
> > Presumably you need a paragraph in the charter relating to=20
> working with other groups (in particular IETF WG) to ensure=20
> that profiled specifications exist and are brought to=20
> standards track level.
> Yes, definitely.
> > regards
> >
> >
> > Keith
> >
> >> -----Original Message-----
> >> From: dispatch-bounces@ietf.org
> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand
> >> Sent: Thursday, January 06, 2011 11:54 AM
> >> To: 'dispatch@ietf.org'
> >> Cc: rtc-web@alvestrand.no
> >> Subject: [dispatch] Charter proposal: The activity=20
> hitherto known as=20
> >> "RTC-WEB at IETF"
> >>
> >> This is the first of 3 messages going to the DISPATCH list (in the=20
> >> hope of keeping discussions somewhat organized).
> >>
> >> This is the draft of a charter for an IETF working group=20
> to consider=20
> >> the subject area of "Real time communication in the Web browser=20
> >> platform".
> >> This is one of a paired set of activities, the other one=20
> being a W3C=20
> >> activity (either within an existing WG or in a new WG)=20
> that defines=20
> >> APIs to this functionality.
> >>
> >> The two other messages will contain the W3C proposed charter and a=20
> >> kickoff for what's usually the most distracting topic in any such
> >> discussion: The name of the group.
> >> Without further ado:
> >>
> >> -------------------------------------
> >>
> >> Version: 2
> >>
> >> Possible Names:
> >> 
> >>
> >> Body:
> >>
> >> Many implementations have been made that use a Web browser=20
> to support=20
> >> interactive communications directly between users including voice,=20
> >> video, collaboration and gaming, but until now, such applications=20
> >> have required the installation of nonstandard plugins and browser=20
> >> extensions.
> >> There is a desire to standardize such functionality, so that this=20
> >> type of application can be run in any compatible browser.
> >>
> >> Traditionally, the W3C has defined API and markup=20
> languages such as=20
> >> HTML that work in conjunction with with the IETF over the wire=20
> >> protocols such as HTTP to allow web browsers to display media that=20
> >> does not have real time interactive constraints with another human.
> >>
> >> The W3C and IETF plan to collaborate together in their traditional=20
> >> way to meet the evolving needs of browsers.
> >> Specifically the IETF will provide a set of on the wire protocols,=20
> >> including RTP, to meet the needs on interactive=20
> communications, and=20
> >> the W3C will define the API and markup to allow web application=20
> >> developers to control the on the wire protocols. This will allow=20
> >> application developers  to write applications that run in=20
> a browser=20
> >> and facilitate interactive communications between users=20
> for voice and=20
> >> video communications, collaboration, and gaming.
> >>
> >> This working group will select and define a minimal set of=20
> protocols=20
> >> that will enable browsers to:
> >>
> >> * have interactive real time voice and video between users=20
> using RTP
> >> * interoperate with compatible voice and video systems=20
> that are not=20
> >> web based
> >> * support direct flows of non RTP application data between=20
> browsers=20
> >> for collaboration and gaming applications
> >>
> >> Fortunately very little development of new protocol at IETF is=20
> >> required for this, only selection of existing protocols=20
> and selection=20
> >> of minimum capabilities to ensure interoperability. The following=20
> >> protocols are candidates for including in the profile set:
> >>
> >> 1) RTP/ RTCP
> >>
> >> 2) a baseline audio codec for high quality interactive audio.
> >> Opus will be considered as one of the candidates
> >>
> >> 3) a baseline audio codec for PSTN interoperability. G.711=20
> and iLBC=20
> >> will be considered
> >>
> >> 4) a baseline video codec. H.264 and VP8 will be considered
> >>
> >> 5) Diffserv based QoS
> >>
> >> 6) NAT traversal using ICE
> >>
> >> 7) RFC 4833 based DTMF transport
> >>
> >> 8) RFC 4574 based Label support for identifying streams purpose
> >>
> >> 9) Secure RTP and keying
> >>
> >> 10) support for IPv4, IPv6 and dual stack browsers
> >>
> >> The working group will cooperate closely with the W3C=20
> activity that=20
> >> specifies a semantic level API that allows the control and=20
> >> manipulation of all the functionality above. In addition, the API=20
> >> needs to communicate state information and events about what is=20
> >> happening in the browser that to applications running in=20
> the browser.=20
> >> These events and state need to include information such=20
> as: receiving=20
> >> RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP,  and=20
> >> signalling state.
> >>
> >> The following topics will be out of scope for the initial phase of=20
> >> the WG but could be added after a recharter: RTSP, RSVP,=20
> NSIS, LOST,=20
> >> Geolocation, IM&  Presence, NSIS, Resource Priority,
> >>
> >> Milestones:
> >>
> >> February 2011 Candidate "sample" documents circulated to DISPATCH
> >>
> >> March 2011 BOF at IETF Prague
> >>
> >> April 2011 WG charter approved by IESG. Chosen document=20
> sets adopted=20
> >> as WG documents
> >>
> >> May 2011 Functionality to include and main alternative protocols=20
> >> identified
> >>
> >> July 2011 IETF meeting
> >>
> >> Aug 2011 Draft with text reflecting agreement of what the protocol=20
> >> set should be
> >>
> >> Nov 2010 Documentation specifying mapping of protocol=20
> functionality=20
> >> to W3C-specified API produced
> >>
> >> Dec 2011 Protocol set specification to IESG
> >>
> >> April 2012 API mapping document to IESG
> >>
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >>
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> =

From juberti@google.com  Thu Jan  6 10:40:22 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09033A6F49 for ; Thu,  6 Jan 2011 10:40:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level: 
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0C2QW8fWpR9s for ; Thu,  6 Jan 2011 10:40:21 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 38DA63A6F47 for ; Thu,  6 Jan 2011 10:40:21 -0800 (PST)
Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p06IgRTe016172 for ; Thu, 6 Jan 2011 10:42:27 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294339347; bh=O79dze2TPZ/sR8cF9XjmFgaezDc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=OGjoLF8J7ugcH1OfwFHLpXDgKntq/ZgflP1g+deHqdAboj9FyTSVnjmhWvZ6Q5iud AXABzSjUk8GsEneoK548Q==
Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by hpaq2.eem.corp.google.com with ESMTP id p06IdQPP025719 for ; Thu, 6 Jan 2011 10:42:26 -0800
Received: by qwj9 with SMTP id 9so17212239qwj.27 for ; Thu, 06 Jan 2011 10:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=6qc0QUF4SpJsrxiZHznEemea67k4ajNMjMWmPtqB+C8=; b=CXlGuecmm3MVZGWxucTQqW7/rLz6AKQuRKSp7YawTmBmDfkZjrJZjAVbZnMAu6ZWGu Syg5HUbKw0QHUYnOtePg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=eIYok4XI37gtILmDDn9oGy4d3Um4Mh9nJ59lEpEhKoGPd2IML65GoUHcCUoEzX+cdX VqjEl94pJ8VTJalHhS/g==
Received: by 10.229.183.147 with SMTP id cg19mr21903496qcb.37.1294339345567; Thu, 06 Jan 2011 10:42:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.135.9 with HTTP; Thu, 6 Jan 2011 10:42:05 -0800 (PST)
In-Reply-To: 
References: <4D25AE32.1020205@alvestrand.no> 
From: Justin Uberti 
Date: Thu, 6 Jan 2011 10:42:05 -0800
Message-ID: 
To: Marshall Eubanks 
Content-Type: multipart/alternative; boundary=00163630fc77e94fd2049931dc9e
X-System-Of-Record: true
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 18:40:22 -0000

--00163630fc77e94fd2049931dc9e
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 6, 2011 at 8:47 AM, Marshall Eubanks  wrote:

>
> On Jan 6, 2011, at 6:57 AM, Harald Alvestrand wrote:
>
> > This activity remains nameless.
> > The requirements for a name are:
> >
> > - It should be cute
> > - It should be easy to remember
> > - It should be easy to associate with the activity
> >
> > If it's also somewhat meaningful, that's a nice benefit.
> > The boring choices include:
> >
> > - RTCWEB
> > - WEBRTC
>
> Here is my proposal, not yet used in the IETF :
>
> REALTIME
>

or, WREALTIME (silent W for 'web')



>
> Marshall
>
> >
> > There are many others out there. I'll try to keep track of suggestions on
> a page at the RTCWeb website (rtc-web.alvestrand.no), and we'll find a way
> to decide after a few suggestions have been made.
> > Let the creativity flow!
> >
> >              Harald
> >
> > _______________________________________________
> > RTC-Web mailing list
> > RTC-Web@alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/rtc-web
> >
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>

--00163630fc77e94fd2049931dc9e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thu, Jan 6, 2011 at 8:47 AM, Marshall=
 Eubanks <tme@am=
ericafree.tv> wrote:





On Jan 6, 2011, at 6:57 AM, Harald Alvestrand wrote:



> This activity remains nameless.

> The requirements for a name are:

>

> - It should be cute

> - It should be easy to remember

> - It should be easy to associate with the activity

>

> If it's also somewhat meaningful, that's a nice benefit.

> The boring choices include:

>

> - RTCWEB

> - WEBRTC




Here is my proposal, not yet used in the IETF :



REALTIME

or, WREALTIME (silent W for &#=
39;web')

=C2=A0





Marshall




>

> There are many others out there. I'll try to keep track of suggest=
ions on a page at the RTCWeb website (rtc-web.alvestrand.no), and we'll find a way =
to decide after a few suggestions have been made.



> Let the creativity flow!

>

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Harald

>

> _______________________________________________

> RTC-Web mailing list

> RTC-Web@alvestrand.no

> http://www.alvestrand.no/mailman/listinfo/rtc-web

>



_______________________________________________

RTC-Web mailing list

RTC-Web@alvestrand.no

http://www.alvestrand.no/mailman/listinfo/rtc-web





--00163630fc77e94fd2049931dc9e--

From ted.ietf@gmail.com  Thu Jan  6 10:41:32 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BB03A6F54 for ; Thu,  6 Jan 2011 10:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.109
X-Spam-Level: 
X-Spam-Status: No, score=-3.109 tagged_above=-999 required=5 tests=[AWL=0.490,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4sJWpEN2eb3 for ; Thu,  6 Jan 2011 10:41:31 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id EBD883A6F35 for ; Thu,  6 Jan 2011 10:41:30 -0800 (PST)
Received: by qwi2 with SMTP id 2so1232747qwi.31 for ; Thu, 06 Jan 2011 10:43:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+i/gVo0penRj+u67MJZm5tjNcdSb4uSWYQoicTB+QQg=; b=Veo2hmQ63OdRFDKol/24uKweNqqog+lYrsCotMgbmx7mxVOgNVFlf2bWacGmE9TWAp FVKNhvH0ffw6StSkdjRKISZTM/EmVqSOJkqaTskz11aKr6YNRs8WOiDaNaLVUcoUIWeV qJYmcfvkUGwJEmKD9Rby+tkjoxV5VcXokLcek=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gQQ94wiPmLiOsEBFbLtR6uG11wUE7oQAbfws2rJkc66yzAnpkaj64fHtCheNrzfzdO oiBQ0Z0IFTuCW/9bvkFfQFzZ23grAl6I8odk4AV4Shjm+wkreAlYJJPvSO3+U6Qh3MuN EnWrKvJOHkyCkt6z0NF7R5iceOtxZvvfnqiV4=
MIME-Version: 1.0
Received: by 10.229.184.1 with SMTP id ci1mr2333575qcb.193.1294339417586; Thu, 06 Jan 2011 10:43:37 -0800 (PST)
Received: by 10.229.230.138 with HTTP; Thu, 6 Jan 2011 10:43:37 -0800 (PST)
In-Reply-To: <4D25AD41.7060306@alvestrand.no>
References: <4D25AD41.7060306@alvestrand.no>
Date: Thu, 6 Jan 2011 10:43:37 -0800
Message-ID: 
From: Ted Hardie 
To: Harald Alvestrand 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 18:41:32 -0000

Hi Harald,

Thanks for putting this together; some discussion in-line.

On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand  wr=
ote:
> This is the first of 3 messages going to the DISPATCH list (in the hope o=
f
> keeping discussions somewhat organized).
>
> This is the draft of a charter for an IETF working group to consider the
> subject area of "Real time communication in the Web browser platform". Th=
is
> is one of a paired set of activities, the other one being a W3C activity
> (either within an existing WG or in a new WG) that defines APIs to this
> functionality.
>
> The two other messages will contain the W3C proposed charter and a kickof=
f
> for what's usually the most distracting topic in any such discussion: The
> name of the group.
> Without further ado:
>
> -------------------------------------
>
> Version: 2
>
> Possible Names:
> 
>
> Body:
>
> Many implementations have been made that use a Web browser to support
> interactive communications directly between users including voice, video,
> collaboration and gaming, but until now, such applications have required =
the
> installation of nonstandard plugins and browser extensions. There is a
> desire to standardize such functionality, so that this type of applicatio=
n
> can be run in any compatible browser.
>

In at least some of the contexts identified above, there is a
long-lived identifier
associated with the individuals who will have interactive
communications; that is,
there is a context-specific presence architecture in addition to the
implementation-specific
real-time communications.  Though the text below occasionally says "users",
there does not seem to be any work being defined that would touch on this.
I see that in the last sentence you explicitly rule it out of scope.
Without this,
this seems to be limited to an architecture where a mediating server provid=
es
the initial signaling path.  If that is the scope, I think that should be m=
ade
explicit as a design statement, not inferred from the lack of presence.

> Traditionally, the W3C has defined API and markup languages such as HTML
> that work in conjunction with with the IETF over the wire protocols such =
as
> HTTP to allow web browsers to display media that does not have real time
> interactive constraints with another human.
>
> The W3C and IETF plan to collaborate together in their traditional way to
> meet the evolving needs of browsers. Specifically the IETF will provide a
> set of on the wire protocols, including RTP, to meet the needs on
> interactive communications, and the W3C will define the API and markup to
> allow web application developers to control the on the wire protocols. Th=
is
> will allow application developers =A0to write applications that run in a
> browser and facilitate interactive communications between users for voice
> and video communications, collaboration, and gaming.
>
> This working group will select and define a minimal set of protocols that
> will enable browsers to:
>
> * have interactive real time voice and video between users using RTP
> * interoperate with compatible voice and video systems that are not web
> based

> * support direct flows of non RTP application data between browsers for
> collaboration and gaming applications
>

Okay "direct flows of non-RTP application data" goes beyond scope creep;
to satisfy this completely, we are talking an end-point-to-end-point tunnel=
,
which will run afoul of a lot of folks who dearly love packet inspection.  =
I
would say that it would be best to first tackle the voice/video bits and th=
en
tackle this problem.  Re-charter the WG to cover this, in other words, afte=
r
the first bit is done.

I also note that you're using "between browsers", rather than "among browse=
rs".
Is it intended that this facility should allow for multi-party communicatio=
n?
Leaving aside the non-RTP issues, that would add floor control, media mixin=
g,
etc. to the task list.  Again, I think it should either be explicitly
in-scope or out-of-scope.

> Fortunately very little development of new protocol at IETF is required f=
or
> this, only selection of existing protocols and selection of minimum
> capabilities to ensure interoperability. The following protocols are
> candidates for including in the profile set:
>
> 1) RTP/ RTCP
>
> 2) a baseline audio codec for high quality interactive audio. Opus
> will be considered as one of the candidates
>
> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
> will be considered
>
> 4) a baseline video codec. H.264 and VP8 will be considered
>
> 5) Diffserv based QoS
>
> 6) NAT traversal using ICE
>

The ICE spec is clear that the NAT traversal it provides does not
help establish the signaling between agents.  For this browser-to-browser
mechanism, if we are limiting this to situations where a mediating web serv=
er
provides the initial signaling path, that's okay.  If there is a
different model, though,
we may need additional tools here.

> 7) RFC 4833 based DTMF transport
>
> 8) RFC 4574 based Label support for identifying streams purpose
>
> 9) Secure RTP and keying
>
> 10) support for IPv4, IPv6 and dual stack browsers
>
> The working group will cooperate closely with the W3C activity that
> specifies a semantic level API that allows the control and manipulation o=
f
> all the functionality above. In addition, the API needs to communicate st=
ate
> information and events about what is happening in the browser that to
> applications running in the browser.

I think the sentence above has some extra words; is the browser talking
to application running in the browser?  Can it be re-phrased?

These events and state need to include
> information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, st=
ate
> of DTLS/SRTP, =A0and signalling state.
>
> The following topics will be out of scope for the initial phase of the WG
> but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocation=
,
> IM & Presence, NSIS, Resource Priority,
>
> Milestones:
>
> February 2011 Candidate "sample" documents circulated to DISPATCH
>
> March 2011 BOF at IETF Prague
>
> April 2011 WG charter approved by IESG. Chosen document sets adopted as W=
G
> documents
>
> May 2011 Functionality to include and main alternative protocols identifi=
ed
>
> July 2011 IETF meeting
>
> Aug 2011 Draft with text reflecting agreement of what the protocol set
> should be
>
> Nov 2010 Documentation specifying mapping of protocol functionality to
> W3C-specified API produced
>
> Dec 2011 Protocol set specification to IESG
>
> April 2012 API mapping document to IESG
>

Pretty aggressive, given the number of moving parts.  It's also not
clear why the November 2011 doc (I assume 2010 is a typo) is
done in the IETF, rather than the W3C.  Or is it joint work?

regards,

Ted Hardie


> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>

From adam@nostrum.com  Thu Jan  6 10:55:26 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0CE93A6E1A for ; Thu,  6 Jan 2011 10:55:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.537
X-Spam-Level: 
X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0MISI9tPvFS for ; Thu,  6 Jan 2011 10:55:26 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 66FD43A6CC6 for ; Thu,  6 Jan 2011 10:55:24 -0800 (PST)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p06IvOxt067374 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Jan 2011 12:57:24 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4D261094.90705@nostrum.com>
Date: Thu, 06 Jan 2011 12:57:24 -0600
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "DRAGE, Keith (Keith)" 
References: <4D25AE32.1020205@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" 
Subject: Re: [dispatch] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 18:55:27 -0000

On 1/6/11 7:49 AM, DRAGE, Keith (Keith) wrote:
> Please stick to boring.
>
> I have the greatest difficulty in remembering what some current RAI WG are about when starting from the acronym.

I have some sympathy for what Keith is saying here. I'm finding it 
difficult to keep up with the actual meanings of the excessively cute 
names (CLUE? LEDBAT? I have to look them up).

Perhaps we could pick something that is concise when spoken, like "WEBCOMM".

/a

From henry.sinnreich@gmail.com  Thu Jan  6 11:17:03 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E22D3A6CFA for ; Thu,  6 Jan 2011 11:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.084
X-Spam-Level: 
X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[AWL=0.515,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajcIDwJm6N75 for ; Thu,  6 Jan 2011 11:17:01 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id EFDA03A6F59 for ; Thu,  6 Jan 2011 11:16:50 -0800 (PST)
Received: by yxt33 with SMTP id 33so7357718yxt.31 for ; Thu, 06 Jan 2011 11:18:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=S7b3Uf3cl85vMfgOvPkMhQKIgdifcPeHStf8XE8uAzs=; b=fWaHgG6NSf4VHCnslHLitn4mYMVLUJTKtT4donFeIBJr4ww9DTWXCR/2pvt26pBTbh 2SCV2D0TJ0uqhPS09h/aMvbA8RF+72k7AwspX4W1S04uPRTb8Q3EqG7lBo/dj3/5+bk9 Lu/azzAeVyXu14YYKmjfMXUCAJrDTRPWFVb04=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=aLT/7U5GbxzoJ2P19nrGKCBGeyTDsU3d90znu5spG9Verg63n4dvvhmSEe1GAgpIBp ngIoVL4tQBMxGSTfu1hiVSJgIEwyFsL0ozpG1/a6ndn2syBtvvWMsL513YYx+Cqp9138 IxhIYqVlurtxGboz0VmKK46UkutOqIzmxABoU=
Received: by 10.150.218.21 with SMTP id q21mr5160356ybg.350.1294341537627; Thu, 06 Jan 2011 11:18:57 -0800 (PST)
Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id v4sm15541781ybe.17.2011.01.06.11.18.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 11:18:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.28.0.101117
Date: Thu, 06 Jan 2011 13:18:52 -0600
From: Henry Sinnreich 
To: Ted Hardie , Harald Alvestrand 
Message-ID: 
Thread-Topic: dearly love packet inspection
Thread-Index: Acut1o2SqVRwidvlVUKKwmA8IIjtYQ==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: [dispatch] dearly love packet inspection
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 19:17:03 -0000

> Okay "direct flows of non-RTP application data" goes beyond scope creep;
> to satisfy this completely, we are talking an end-point-to-end-point tunn=
el,
> which will run afoul of a lot of folks who dearly love packet inspection.

Why should the IETF and W3C abide by the folks who love deep packet
inspection? I would like to see some IESG guidance here, since it is
contrary to Internet and to the Web. Break of privacy, etc.

To accelerate clarity here, what does Harald and people on the list think?

Thanks, Henry


On 1/6/11 12:43 PM, "Ted Hardie"  wrote:

> Hi Harald,
>=20
> Thanks for putting this together; some discussion in-line.
>=20
> On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand 
> wrote:
>> This is the first of 3 messages going to the DISPATCH list (in the hope =
of
>> keeping discussions somewhat organized).
>>=20
>> This is the draft of a charter for an IETF working group to consider the
>> subject area of "Real time communication in the Web browser platform". T=
his
>> is one of a paired set of activities, the other one being a W3C activity
>> (either within an existing WG or in a new WG) that defines APIs to this
>> functionality.
>>=20
>> The two other messages will contain the W3C proposed charter and a kicko=
ff
>> for what's usually the most distracting topic in any such discussion: Th=
e
>> name of the group.
>> Without further ado:
>>=20
>> -------------------------------------
>>=20
>> Version: 2
>>=20
>> Possible Names:
>> 
>>=20
>> Body:
>>=20
>> Many implementations have been made that use a Web browser to support
>> interactive communications directly between users including voice, video=
,
>> collaboration and gaming, but until now, such applications have required=
 the
>> installation of nonstandard plugins and browser extensions. There is a
>> desire to standardize such functionality, so that this type of applicati=
on
>> can be run in any compatible browser.
>>=20
>=20
> In at least some of the contexts identified above, there is a
> long-lived identifier
> associated with the individuals who will have interactive
> communications; that is,
> there is a context-specific presence architecture in addition to the
> implementation-specific
> real-time communications.  Though the text below occasionally says "users=
",
> there does not seem to be any work being defined that would touch on this=
.
> I see that in the last sentence you explicitly rule it out of scope.
> Without this,
> this seems to be limited to an architecture where a mediating server prov=
ides
> the initial signaling path.  If that is the scope, I think that should be=
 made
> explicit as a design statement, not inferred from the lack of presence.
>=20
>> Traditionally, the W3C has defined API and markup languages such as HTML
>> that work in conjunction with with the IETF over the wire protocols such=
 as
>> HTTP to allow web browsers to display media that does not have real time
>> interactive constraints with another human.
>>=20
>> The W3C and IETF plan to collaborate together in their traditional way t=
o
>> meet the evolving needs of browsers. Specifically the IETF will provide =
a
>> set of on the wire protocols, including RTP, to meet the needs on
>> interactive communications, and the W3C will define the API and markup t=
o
>> allow web application developers to control the on the wire protocols. T=
his
>> will allow application developers =A0to write applications that run in a
>> browser and facilitate interactive communications between users for voic=
e
>> and video communications, collaboration, and gaming.
>>=20
>> This working group will select and define a minimal set of protocols tha=
t
>> will enable browsers to:
>>=20
>> * have interactive real time voice and video between users using RTP
>> * interoperate with compatible voice and video systems that are not web
>> based
>=20
>> * support direct flows of non RTP application data between browsers for
>> collaboration and gaming applications
>>=20
>=20
> Okay "direct flows of non-RTP application data" goes beyond scope creep;
> to satisfy this completely, we are talking an end-point-to-end-point tunn=
el,
> which will run afoul of a lot of folks who dearly love packet inspection.=
  I
> would say that it would be best to first tackle the voice/video bits and =
then
> tackle this problem.  Re-charter the WG to cover this, in other words, af=
ter
> the first bit is done.
>=20
> I also note that you're using "between browsers", rather than "among
> browsers".
> Is it intended that this facility should allow for multi-party communicat=
ion?
> Leaving aside the non-RTP issues, that would add floor control, media mix=
ing,
> etc. to the task list.  Again, I think it should either be explicitly
> in-scope or out-of-scope.
>=20
>> Fortunately very little development of new protocol at IETF is required =
for
>> this, only selection of existing protocols and selection of minimum
>> capabilities to ensure interoperability. The following protocols are
>> candidates for including in the profile set:
>>=20
>> 1) RTP/ RTCP
>>=20
>> 2) a baseline audio codec for high quality interactive audio. Opus
>> will be considered as one of the candidates
>>=20
>> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
>> will be considered
>>=20
>> 4) a baseline video codec. H.264 and VP8 will be considered
>>=20
>> 5) Diffserv based QoS
>>=20
>> 6) NAT traversal using ICE
>>=20
>=20
> The ICE spec is clear that the NAT traversal it provides does not
> help establish the signaling between agents.  For this browser-to-browser
> mechanism, if we are limiting this to situations where a mediating web se=
rver
> provides the initial signaling path, that's okay.  If there is a
> different model, though,
> we may need additional tools here.
>=20
>> 7) RFC 4833 based DTMF transport
>>=20
>> 8) RFC 4574 based Label support for identifying streams purpose
>>=20
>> 9) Secure RTP and keying
>>=20
>> 10) support for IPv4, IPv6 and dual stack browsers
>>=20
>> The working group will cooperate closely with the W3C activity that
>> specifies a semantic level API that allows the control and manipulation =
of
>> all the functionality above. In addition, the API needs to communicate s=
tate
>> information and events about what is happening in the browser that to
>> applications running in the browser.
>=20
> I think the sentence above has some extra words; is the browser talking
> to application running in the browser?  Can it be re-phrased?
>=20
> These events and state need to include
>> information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, s=
tate
>> of DTLS/SRTP, =A0and signalling state.
>>=20
>> The following topics will be out of scope for the initial phase of the W=
G
>> but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocatio=
n,
>> IM & Presence, NSIS, Resource Priority,
>>=20
>> Milestones:
>>=20
>> February 2011 Candidate "sample" documents circulated to DISPATCH
>>=20
>> March 2011 BOF at IETF Prague
>>=20
>> April 2011 WG charter approved by IESG. Chosen document sets adopted as =
WG
>> documents
>>=20
>> May 2011 Functionality to include and main alternative protocols identif=
ied
>>=20
>> July 2011 IETF meeting
>>=20
>> Aug 2011 Draft with text reflecting agreement of what the protocol set
>> should be
>>=20
>> Nov 2010 Documentation specifying mapping of protocol functionality to
>> W3C-specified API produced
>>=20
>> Dec 2011 Protocol set specification to IESG
>>=20
>> April 2012 API mapping document to IESG
>>=20
>=20
> Pretty aggressive, given the number of moving parts.  It's also not
> clear why the November 2011 doc (I assume 2010 is a typo) is
> done in the IETF, rather than the W3C.  Or is it joint work?
>=20
> regards,
>=20
> Ted Hardie
>=20
>=20
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web@alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch



From ted.ietf@gmail.com  Thu Jan  6 11:35:23 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9DDA3A6D06 for ; Thu,  6 Jan 2011 11:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.125
X-Spam-Level: 
X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=0.474,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbTSS1kk3QMA for ; Thu,  6 Jan 2011 11:35:22 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 1CD8A3A6CAB for ; Thu,  6 Jan 2011 11:35:22 -0800 (PST)
Received: by qwi2 with SMTP id 2so1284670qwi.31 for ; Thu, 06 Jan 2011 11:37:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2j8Oozx2Ufkg4QLg4GTaKtEFl5tyKkS/yRTFaxKUzig=; b=holil33mRyEQpahjesN8qR+FVRmX+0TA0MjgsYxDngINjHZCDDyTbm8m+8THbUSUNG /t29lyQymRE4JgJBXHrywzzgS5SdqfHDfbumxIGBxY50fLjr8ndQjHS58XBldXx8IuZY aMe6QueStG9mXy7iUm+pAIMq9k+lY8aNtHEns=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ogyp1DbrIyeKefO45tzWr/hFmJPuAUBLW/H+8Cr7m4GM2qa9uxfHzED1sKoXNcqxbJ pnO06JRUUGb8ADEYaNyANkrlP2SgZzE1IrawO9LGSh6R794WgVntRgSPPugkMmfGbGo7 hCx/no9ELRjn43t2Wnw25smF7DvDU/c+g++pw=
MIME-Version: 1.0
Received: by 10.229.96.132 with SMTP id h4mr21770447qcn.41.1294342648154; Thu, 06 Jan 2011 11:37:28 -0800 (PST)
Received: by 10.229.230.138 with HTTP; Thu, 6 Jan 2011 11:37:28 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 6 Jan 2011 11:37:28 -0800
Message-ID: 
From: Ted Hardie 
To: Henry Sinnreich 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] dearly love packet inspection
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 19:35:23 -0000

On Thu, Jan 6, 2011 at 11:18 AM, Henry Sinnreich
 wrote:
>> Okay "direct flows of non-RTP application data" goes beyond scope creep;
>> to satisfy this completely, we are talking an end-point-to-end-point tun=
nel,
>> which will run afoul of a lot of folks who dearly love packet inspection=
.
>
> Why should the IETF and W3C abide by the folks who love deep packet
> inspection? I would like to see some IESG guidance here, since it is
> contrary to Internet and to the Web. Break of privacy, etc.
>
> To accelerate clarity here, what does Harald and people on the list think=
?
>
> Thanks, Henry

Hi Henry,

I'm not a huge fan of packet inspection.  But "any application data" is cle=
arly
well beyond the audio/video use case that motivated this work in the first
place.  I expect that it would make firewall traversal significantly
harder unless
it lost privacy; that trade-off would make the voice/video privacy *worse*.

It also will make the communication among browsers in a multi-party
mode move from known issues (media mixing and floor control) to something
closer to that of an overlay network.  That's not impossible (setting
up an overlay
when you have a rendezvous server, basically moves it from mediating
the signaling
path to being an enrollment server), but is also not simple.  Is it
really needed
for job one here?

regards,

Ted



>
>
> On 1/6/11 12:43 PM, "Ted Hardie"  wrote:
>
>> Hi Harald,
>>
>> Thanks for putting this together; some discussion in-line.
>>
>> On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand 
>> wrote:
>>> This is the first of 3 messages going to the DISPATCH list (in the hope=
 of
>>> keeping discussions somewhat organized).
>>>
>>> This is the draft of a charter for an IETF working group to consider th=
e
>>> subject area of "Real time communication in the Web browser platform". =
This
>>> is one of a paired set of activities, the other one being a W3C activit=
y
>>> (either within an existing WG or in a new WG) that defines APIs to this
>>> functionality.
>>>
>>> The two other messages will contain the W3C proposed charter and a kick=
off
>>> for what's usually the most distracting topic in any such discussion: T=
he
>>> name of the group.
>>> Without further ado:
>>>
>>> -------------------------------------
>>>
>>> Version: 2
>>>
>>> Possible Names:
>>> 
>>>
>>> Body:
>>>
>>> Many implementations have been made that use a Web browser to support
>>> interactive communications directly between users including voice, vide=
o,
>>> collaboration and gaming, but until now, such applications have require=
d the
>>> installation of nonstandard plugins and browser extensions. There is a
>>> desire to standardize such functionality, so that this type of applicat=
ion
>>> can be run in any compatible browser.
>>>
>>
>> In at least some of the contexts identified above, there is a
>> long-lived identifier
>> associated with the individuals who will have interactive
>> communications; that is,
>> there is a context-specific presence architecture in addition to the
>> implementation-specific
>> real-time communications. =A0Though the text below occasionally says "us=
ers",
>> there does not seem to be any work being defined that would touch on thi=
s.
>> I see that in the last sentence you explicitly rule it out of scope.
>> Without this,
>> this seems to be limited to an architecture where a mediating server pro=
vides
>> the initial signaling path. =A0If that is the scope, I think that should=
 be made
>> explicit as a design statement, not inferred from the lack of presence.
>>
>>> Traditionally, the W3C has defined API and markup languages such as HTM=
L
>>> that work in conjunction with with the IETF over the wire protocols suc=
h as
>>> HTTP to allow web browsers to display media that does not have real tim=
e
>>> interactive constraints with another human.
>>>
>>> The W3C and IETF plan to collaborate together in their traditional way =
to
>>> meet the evolving needs of browsers. Specifically the IETF will provide=
 a
>>> set of on the wire protocols, including RTP, to meet the needs on
>>> interactive communications, and the W3C will define the API and markup =
to
>>> allow web application developers to control the on the wire protocols. =
This
>>> will allow application developers =A0to write applications that run in =
a
>>> browser and facilitate interactive communications between users for voi=
ce
>>> and video communications, collaboration, and gaming.
>>>
>>> This working group will select and define a minimal set of protocols th=
at
>>> will enable browsers to:
>>>
>>> * have interactive real time voice and video between users using RTP
>>> * interoperate with compatible voice and video systems that are not web
>>> based
>>
>>> * support direct flows of non RTP application data between browsers for
>>> collaboration and gaming applications
>>>
>>
>> Okay "direct flows of non-RTP application data" goes beyond scope creep;
>> to satisfy this completely, we are talking an end-point-to-end-point tun=
nel,
>> which will run afoul of a lot of folks who dearly love packet inspection=
. =A0I
>> would say that it would be best to first tackle the voice/video bits and=
 then
>> tackle this problem. =A0Re-charter the WG to cover this, in other words,=
 after
>> the first bit is done.
>>
>> I also note that you're using "between browsers", rather than "among
>> browsers".
>> Is it intended that this facility should allow for multi-party communica=
tion?
>> Leaving aside the non-RTP issues, that would add floor control, media mi=
xing,
>> etc. to the task list. =A0Again, I think it should either be explicitly
>> in-scope or out-of-scope.
>>
>>> Fortunately very little development of new protocol at IETF is required=
 for
>>> this, only selection of existing protocols and selection of minimum
>>> capabilities to ensure interoperability. The following protocols are
>>> candidates for including in the profile set:
>>>
>>> 1) RTP/ RTCP
>>>
>>> 2) a baseline audio codec for high quality interactive audio. Opus
>>> will be considered as one of the candidates
>>>
>>> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
>>> will be considered
>>>
>>> 4) a baseline video codec. H.264 and VP8 will be considered
>>>
>>> 5) Diffserv based QoS
>>>
>>> 6) NAT traversal using ICE
>>>
>>
>> The ICE spec is clear that the NAT traversal it provides does not
>> help establish the signaling between agents. =A0For this browser-to-brow=
ser
>> mechanism, if we are limiting this to situations where a mediating web s=
erver
>> provides the initial signaling path, that's okay. =A0If there is a
>> different model, though,
>> we may need additional tools here.
>>
>>> 7) RFC 4833 based DTMF transport
>>>
>>> 8) RFC 4574 based Label support for identifying streams purpose
>>>
>>> 9) Secure RTP and keying
>>>
>>> 10) support for IPv4, IPv6 and dual stack browsers
>>>
>>> The working group will cooperate closely with the W3C activity that
>>> specifies a semantic level API that allows the control and manipulation=
 of
>>> all the functionality above. In addition, the API needs to communicate =
state
>>> information and events about what is happening in the browser that to
>>> applications running in the browser.
>>
>> I think the sentence above has some extra words; is the browser talking
>> to application running in the browser? =A0Can it be re-phrased?
>>
>> These events and state need to include
>>> information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, =
state
>>> of DTLS/SRTP, =A0and signalling state.
>>>
>>> The following topics will be out of scope for the initial phase of the =
WG
>>> but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocati=
on,
>>> IM & Presence, NSIS, Resource Priority,
>>>
>>> Milestones:
>>>
>>> February 2011 Candidate "sample" documents circulated to DISPATCH
>>>
>>> March 2011 BOF at IETF Prague
>>>
>>> April 2011 WG charter approved by IESG. Chosen document sets adopted as=
 WG
>>> documents
>>>
>>> May 2011 Functionality to include and main alternative protocols identi=
fied
>>>
>>> July 2011 IETF meeting
>>>
>>> Aug 2011 Draft with text reflecting agreement of what the protocol set
>>> should be
>>>
>>> Nov 2010 Documentation specifying mapping of protocol functionality to
>>> W3C-specified API produced
>>>
>>> Dec 2011 Protocol set specification to IESG
>>>
>>> April 2012 API mapping document to IESG
>>>
>>
>> Pretty aggressive, given the number of moving parts. =A0It's also not
>> clear why the November 2011 doc (I assume 2010 is a typo) is
>> done in the IETF, rather than the W3C. =A0Or is it joint work?
>>
>> regards,
>>
>> Ted Hardie
>>
>>
>>> _______________________________________________
>>> RTC-Web mailing list
>>> RTC-Web@alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>

From tme@americafree.tv  Thu Jan  6 11:44:34 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084413A6E1A for ; Thu,  6 Jan 2011 11:44:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.202
X-Spam-Level: 
X-Spam-Status: No, score=-102.202 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwDLNkStkwDo for ; Thu,  6 Jan 2011 11:44:32 -0800 (PST)
Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 23B483A6D06 for ; Thu,  6 Jan 2011 11:44:32 -0800 (PST)
Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 66EC19972163; Thu,  6 Jan 2011 14:46:38 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Marshall Eubanks 
In-Reply-To: 
Date: Thu, 6 Jan 2011 14:46:37 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <111AF3FF-F6B6-4A9B-AD13-DC58A495B739@americafree.tv>
References: 
To: Henry Sinnreich 
X-Mailer: Apple Mail (2.1081)
Cc: Harald Alvestrand , Ted Hardie , "dispatch@ietf.org" , "rtc-web@alvestrand.no" 
Subject: Re: [dispatch] [RTW] dearly love packet inspection
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 19:44:34 -0000

On Jan 6, 2011, at 2:18 PM, Henry Sinnreich wrote:

>> Okay "direct flows of non-RTP application data" goes beyond scope =
creep;
>> to satisfy this completely, we are talking an end-point-to-end-point =
tunnel,
>> which will run afoul of a lot of folks who dearly love packet =
inspection.
>=20
> Why should the IETF and W3C abide by the folks who love deep packet
> inspection? I would like to see some IESG guidance here, since it is
> contrary to Internet and to the Web. Break of privacy, etc.
>=20
> To accelerate clarity here, what does Harald and people on the list =
think?

As far as I know, there have never had any DPI concerns raised in AMT, =
which is a tunneling protocol (which
might BTW have useful pieces if tunneling is needed here).=20

http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-10

Regards
Marshall


>=20
> Thanks, Henry
>=20
>=20
> On 1/6/11 12:43 PM, "Ted Hardie"  wrote:
>=20
>> Hi Harald,
>>=20
>> Thanks for putting this together; some discussion in-line.
>>=20
>> On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand =

>> wrote:
>>> This is the first of 3 messages going to the DISPATCH list (in the =
hope of
>>> keeping discussions somewhat organized).
>>>=20
>>> This is the draft of a charter for an IETF working group to consider =
the
>>> subject area of "Real time communication in the Web browser =
platform". This
>>> is one of a paired set of activities, the other one being a W3C =
activity
>>> (either within an existing WG or in a new WG) that defines APIs to =
this
>>> functionality.
>>>=20
>>> The two other messages will contain the W3C proposed charter and a =
kickoff
>>> for what's usually the most distracting topic in any such =
discussion: The
>>> name of the group.
>>> Without further ado:
>>>=20
>>> -------------------------------------
>>>=20
>>> Version: 2
>>>=20
>>> Possible Names:
>>> 
>>>=20
>>> Body:
>>>=20
>>> Many implementations have been made that use a Web browser to =
support
>>> interactive communications directly between users including voice, =
video,
>>> collaboration and gaming, but until now, such applications have =
required the
>>> installation of nonstandard plugins and browser extensions. There is =
a
>>> desire to standardize such functionality, so that this type of =
application
>>> can be run in any compatible browser.
>>>=20
>>=20
>> In at least some of the contexts identified above, there is a
>> long-lived identifier
>> associated with the individuals who will have interactive
>> communications; that is,
>> there is a context-specific presence architecture in addition to the
>> implementation-specific
>> real-time communications.  Though the text below occasionally says =
"users",
>> there does not seem to be any work being defined that would touch on =
this.
>> I see that in the last sentence you explicitly rule it out of scope.
>> Without this,
>> this seems to be limited to an architecture where a mediating server =
provides
>> the initial signaling path.  If that is the scope, I think that =
should be made
>> explicit as a design statement, not inferred from the lack of =
presence.
>>=20
>>> Traditionally, the W3C has defined API and markup languages such as =
HTML
>>> that work in conjunction with with the IETF over the wire protocols =
such as
>>> HTTP to allow web browsers to display media that does not have real =
time
>>> interactive constraints with another human.
>>>=20
>>> The W3C and IETF plan to collaborate together in their traditional =
way to
>>> meet the evolving needs of browsers. Specifically the IETF will =
provide a
>>> set of on the wire protocols, including RTP, to meet the needs on
>>> interactive communications, and the W3C will define the API and =
markup to
>>> allow web application developers to control the on the wire =
protocols. This
>>> will allow application developers  to write applications that run in =
a
>>> browser and facilitate interactive communications between users for =
voice
>>> and video communications, collaboration, and gaming.
>>>=20
>>> This working group will select and define a minimal set of protocols =
that
>>> will enable browsers to:
>>>=20
>>> * have interactive real time voice and video between users using RTP
>>> * interoperate with compatible voice and video systems that are not =
web
>>> based
>>=20
>>> * support direct flows of non RTP application data between browsers =
for
>>> collaboration and gaming applications
>>>=20
>>=20
>> Okay "direct flows of non-RTP application data" goes beyond scope =
creep;
>> to satisfy this completely, we are talking an end-point-to-end-point =
tunnel,
>> which will run afoul of a lot of folks who dearly love packet =
inspection.  I
>> would say that it would be best to first tackle the voice/video bits =
and then
>> tackle this problem.  Re-charter the WG to cover this, in other =
words, after
>> the first bit is done.
>>=20
>> I also note that you're using "between browsers", rather than "among
>> browsers".
>> Is it intended that this facility should allow for multi-party =
communication?
>> Leaving aside the non-RTP issues, that would add floor control, media =
mixing,
>> etc. to the task list.  Again, I think it should either be explicitly
>> in-scope or out-of-scope.
>>=20
>>> Fortunately very little development of new protocol at IETF is =
required for
>>> this, only selection of existing protocols and selection of minimum
>>> capabilities to ensure interoperability. The following protocols are
>>> candidates for including in the profile set:
>>>=20
>>> 1) RTP/ RTCP
>>>=20
>>> 2) a baseline audio codec for high quality interactive audio. Opus
>>> will be considered as one of the candidates
>>>=20
>>> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
>>> will be considered
>>>=20
>>> 4) a baseline video codec. H.264 and VP8 will be considered
>>>=20
>>> 5) Diffserv based QoS
>>>=20
>>> 6) NAT traversal using ICE
>>>=20
>>=20
>> The ICE spec is clear that the NAT traversal it provides does not
>> help establish the signaling between agents.  For this =
browser-to-browser
>> mechanism, if we are limiting this to situations where a mediating =
web server
>> provides the initial signaling path, that's okay.  If there is a
>> different model, though,
>> we may need additional tools here.
>>=20
>>> 7) RFC 4833 based DTMF transport
>>>=20
>>> 8) RFC 4574 based Label support for identifying streams purpose
>>>=20
>>> 9) Secure RTP and keying
>>>=20
>>> 10) support for IPv4, IPv6 and dual stack browsers
>>>=20
>>> The working group will cooperate closely with the W3C activity that
>>> specifies a semantic level API that allows the control and =
manipulation of
>>> all the functionality above. In addition, the API needs to =
communicate state
>>> information and events about what is happening in the browser that =
to
>>> applications running in the browser.
>>=20
>> I think the sentence above has some extra words; is the browser =
talking
>> to application running in the browser?  Can it be re-phrased?
>>=20
>> These events and state need to include
>>> information such as: receiving RFC 4833 DTMF, RTP and RTCP =
statistics, state
>>> of DTLS/SRTP,  and signalling state.
>>>=20
>>> The following topics will be out of scope for the initial phase of =
the WG
>>> but could be added after a recharter: RTSP, RSVP, NSIS, LOST, =
Geolocation,
>>> IM & Presence, NSIS, Resource Priority,
>>>=20
>>> Milestones:
>>>=20
>>> February 2011 Candidate "sample" documents circulated to DISPATCH
>>>=20
>>> March 2011 BOF at IETF Prague
>>>=20
>>> April 2011 WG charter approved by IESG. Chosen document sets adopted =
as WG
>>> documents
>>>=20
>>> May 2011 Functionality to include and main alternative protocols =
identified
>>>=20
>>> July 2011 IETF meeting
>>>=20
>>> Aug 2011 Draft with text reflecting agreement of what the protocol =
set
>>> should be
>>>=20
>>> Nov 2010 Documentation specifying mapping of protocol functionality =
to
>>> W3C-specified API produced
>>>=20
>>> Dec 2011 Protocol set specification to IESG
>>>=20
>>> April 2012 API mapping document to IESG
>>>=20
>>=20
>> Pretty aggressive, given the number of moving parts.  It's also not
>> clear why the November 2011 doc (I assume 2010 is a typo) is
>> done in the IETF, rather than the W3C.  Or is it joint work?
>>=20
>> regards,
>>=20
>> Ted Hardie
>>=20
>>=20
>>> _______________________________________________
>>> RTC-Web mailing list
>>> RTC-Web@alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>=20
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>=20
>=20
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>=20


From tme@americafree.tv  Thu Jan  6 12:45:14 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041183A6CFF for ; Thu,  6 Jan 2011 12:45:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.205
X-Spam-Level: 
X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkqwwSfHh+ke for ; Thu,  6 Jan 2011 12:45:12 -0800 (PST)
Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id A32E13A6A94 for ; Thu,  6 Jan 2011 12:45:12 -0800 (PST)
Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 44D8F997345B; Thu,  6 Jan 2011 15:47:19 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Marshall Eubanks 
In-Reply-To: 
Date: Thu, 6 Jan 2011 15:47:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <04BD8059-3B89-4F31-88CA-70F4D83ED553@americafree.tv>
References: <4D25AE32.1020205@alvestrand.no>  
To: Justin Uberti 
X-Mailer: Apple Mail (2.1081)
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 20:45:14 -0000

On Jan 6, 2011, at 1:42 PM, Justin Uberti wrote:

>=20
>=20
> On Thu, Jan 6, 2011 at 8:47 AM, Marshall Eubanks  =
wrote:
>=20
> On Jan 6, 2011, at 6:57 AM, Harald Alvestrand wrote:
>=20
> > This activity remains nameless.
> > The requirements for a name are:
> >
> > - It should be cute
> > - It should be easy to remember
> > - It should be easy to associate with the activity
> >
> > If it's also somewhat meaningful, that's a nice benefit.
> > The boring choices include:
> >
> > - RTCWEB
> > - WEBRTC
>=20
> Here is my proposal, not yet used in the IETF :
>=20
> REALTIME
>=20
> or, WREALTIME (silent W for 'web')
>=20

Or, if REALTIME is too general

WEBTIME

Marshall

> =20
>=20
> Marshall
>=20
> >
> > There are many others out there. I'll try to keep track of =
suggestions on a page at the RTCWeb website (rtc-web.alvestrand.no), and =
we'll find a way to decide after a few suggestions have been made.
> > Let the creativity flow!
> >
> >              Harald
> >
> > _______________________________________________
> > RTC-Web mailing list
> > RTC-Web@alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/rtc-web
> >
>=20
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>=20


From christer.holmberg@ericsson.com  Thu Jan  6 12:51:16 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F53B3A6F44 for ; Thu,  6 Jan 2011 12:51:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.43
X-Spam-Level: 
X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCQrUMegbo9p for ; Thu,  6 Jan 2011 12:51:14 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CEC513A6CFF for ; Thu,  6 Jan 2011 12:51:13 -0800 (PST)
X-AuditID: c1b4fb3d-b7b89ae0000036a3-30-4d262bbfb9a5
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B3.5A.13987.FBB262D4; Thu,  6 Jan 2011 21:53:19 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 6 Jan 2011 21:53:18 +0100
From: Christer Holmberg 
To: Marshall Eubanks , Justin Uberti 
Date: Thu, 6 Jan 2011 21:51:42 +0100
Thread-Topic: [dispatch] [RTW] Name discussion: What is the name of the WG that does the RTC-Web stuff?
Thread-Index: Acut4uvLBwdH8UyORdSIiOLwVi7FJQAAJoJh
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850482F0DF@ESESSCMS0356.eemea.ericsson.se>
References: <4D25AE32.1020205@alvestrand.no>  , <04BD8059-3B89-4F31-88CA-70F4D83ED553@americafree.tv>
In-Reply-To: <04BD8059-3B89-4F31-88CA-70F4D83ED553@americafree.tv>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG	that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 20:51:16 -0000

WHEELTIME

Regards,

Christer

________________________________________
From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Ma=
rshall Eubanks [tme@americafree.tv]
Sent: Thursday, January 06, 2011 10:47 PM
To: Justin Uberti
Cc: Harald Alvestrand; rtc-web@alvestrand.no; dispatch@ietf.org
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG  =
     that does the RTC-Web stuff?

On Jan 6, 2011, at 1:42 PM, Justin Uberti wrote:

>
>
> On Thu, Jan 6, 2011 at 8:47 AM, Marshall Eubanks  wro=
te:
>
> On Jan 6, 2011, at 6:57 AM, Harald Alvestrand wrote:
>
> > This activity remains nameless.
> > The requirements for a name are:
> >
> > - It should be cute
> > - It should be easy to remember
> > - It should be easy to associate with the activity
> >
> > If it's also somewhat meaningful, that's a nice benefit.
> > The boring choices include:
> >
> > - RTCWEB
> > - WEBRTC
>
> Here is my proposal, not yet used in the IETF :
>
> REALTIME
>
> or, WREALTIME (silent W for 'web')
>

Or, if REALTIME is too general

WEBTIME

Marshall

>
>
> Marshall
>
> >
> > There are many others out there. I'll try to keep track of suggestions =
on a page at the RTCWeb website (rtc-web.alvestrand.no), and we'll find a w=
ay to decide after a few suggestions have been made.
> > Let the creativity flow!
> >
> >              Harald
> >
> > _______________________________________________
> > RTC-Web mailing list
> > RTC-Web@alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/rtc-web
> >
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

From harald@alvestrand.no  Thu Jan  6 12:52:43 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1004D3A6C9F for ; Thu,  6 Jan 2011 12:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level: 
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFZs--QgNVsH for ; Thu,  6 Jan 2011 12:52:42 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 25D053A6A94 for ; Thu,  6 Jan 2011 12:52:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9BFC739E15D; Thu,  6 Jan 2011 21:54:24 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuOQuPWRe8R4; Thu,  6 Jan 2011 21:54:24 +0100 (CET)
Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 08F2539E04C; Thu,  6 Jan 2011 21:54:23 +0100 (CET)
Message-ID: <4D262C15.2080702@alvestrand.no>
Date: Thu, 06 Jan 2011 21:54:45 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: Henry Sinnreich 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Ted Hardie , "dispatch@ietf.org" , "rtc-web@alvestrand.no" 
Subject: Re: [dispatch] dearly love packet inspection
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 20:52:43 -0000

On 01/06/11 20:18, Henry Sinnreich wrote:
>> Okay "direct flows of non-RTP application data" goes beyond scope creep;
>> to satisfy this completely, we are talking an end-point-to-end-point tunnel,
>> which will run afoul of a lot of folks who dearly love packet inspection.
> Why should the IETF and W3C abide by the folks who love deep packet
> inspection? I would like to see some IESG guidance here, since it is
> contrary to Internet and to the Web. Break of privacy, etc.
>
> To accelerate clarity here, what does Harald and people on the list think?
My personal opinion:

At the workshop, several use cases were identified where stuff that is 
not audio or video needed to be communicated from one browser to another 
quickly enough that relaying via backend web server(s) is problematic - 
the canonical poster child is the movement of bullets in a first-person 
shooter game, but there are other cases; I think Lisa mentioned that in 
Second Life, the placement of audio sources in the stereo field needs to 
be communicated reasonably synchronously with the sound itself.

I am hesitant to rule point-to-point traffic that isn't audio or video 
out of scope, given the discussion at the workshop; certainly, given the 
RAVEN RFC (RFC 2804), I do not want to rule it out of scope because it's 
hard to write packet inspection state machines that can tell what's 
going on here.

                        Harald


From juberti@google.com  Thu Jan  6 13:23:37 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA223A6CEC for ; Thu,  6 Jan 2011 13:23:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.576
X-Spam-Level: 
X-Spam-Status: No, score=-103.576 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk58cAmgZEWb for ; Thu,  6 Jan 2011 13:23:35 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6C0A23A6B9E for ; Thu,  6 Jan 2011 13:23:33 -0800 (PST)
Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p06LPdLC025355 for ; Thu, 6 Jan 2011 13:25:39 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294349140; bh=9/vapKWO72mic9w4N4fw2I1UpJw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=KvUlYS2YP1AKmXYCOolpHUVbHD2w8u9jm5z1PMRPjp2NOKKTPaVknIUQoDQQEn9m2 HlhJsAj7a5489+l2+fw6A==
Received: from qwk3 (qwk3.prod.google.com [10.241.195.131]) by kpbe11.cbf.corp.google.com with ESMTP id p06LPceB007369 for ; Thu, 6 Jan 2011 13:25:38 -0800
Received: by qwk3 with SMTP id 3so16669432qwk.30 for ; Thu, 06 Jan 2011 13:25:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=xl2yNOqvzyOORYux0eVXWj6LpKjzXjUpNHqRoKBE0nY=; b=FPpRTOK6YFUHOhrKVGSpOg8+etXkuW9vN3YCwYurgHVDfFegJ8Fjoh7SYi7/1ypCeq 3cM6CRAFwa0U1jFi0/Aw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Y/+oAJSk9s2iYA2UHcWQ6ZSrIOCtUyTUKORdHdGMEaJr8X5E74AI/7w5rL1ooDR4GY 5Thz5BUfLDE5FORrJp2Q==
Received: by 10.229.241.69 with SMTP id ld5mr11608306qcb.189.1294349137710; Thu, 06 Jan 2011 13:25:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.135.9 with HTTP; Thu, 6 Jan 2011 13:25:17 -0800 (PST)
In-Reply-To: <4D262C15.2080702@alvestrand.no>
References:  <4D262C15.2080702@alvestrand.no>
From: Justin Uberti 
Date: Thu, 6 Jan 2011 13:25:17 -0800
Message-ID: 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=00163630e87191909e04993424e4
X-System-Of-Record: true
Cc: Ted Hardie , "dispatch@ietf.org" , "rtc-web@alvestrand.no" 
Subject: Re: [dispatch] [RTW] dearly love packet inspection
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 21:23:37 -0000

--00163630e87191909e04993424e4
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 6, 2011 at 12:54 PM, Harald Alvestrand wrote:

> On 01/06/11 20:18, Henry Sinnreich wrote:
>
>> Okay "direct flows of non-RTP application data" goes beyond scope creep;
>>> to satisfy this completely, we are talking an end-point-to-end-point
>>> tunnel,
>>> which will run afoul of a lot of folks who dearly love packet inspection.
>>>
>> Why should the IETF and W3C abide by the folks who love deep packet
>> inspection? I would like to see some IESG guidance here, since it is
>> contrary to Internet and to the Web. Break of privacy, etc.
>>
>> To accelerate clarity here, what does Harald and people on the list think?
>>
> My personal opinion:
>
> At the workshop, several use cases were identified where stuff that is not
> audio or video needed to be communicated from one browser to another quickly
> enough that relaying via backend web server(s) is problematic - the
> canonical poster child is the movement of bullets in a first-person shooter
> game, but there are other cases; I think Lisa mentioned that in Second Life,
> the placement of audio sources in the stereo field needs to be communicated
> reasonably synchronously with the sound itself.
>
> I am hesitant to rule point-to-point traffic that isn't audio or video out
> of scope, given the discussion at the workshop; certainly, given the RAVEN
> RFC (RFC 2804), I do not want to rule it out of scope because it's hard to
> write packet inspection state machines that can tell what's going on here.
>

Right. The thinking was that since we need to do a fair amount of work to
allow audio and video to be exchanged safely and reliably peer-to-peer, we
should allow web applications (with some limits) to use this transport
mechanism for exchanging their own application data.

The plan also is to be able to leverage DTLS to allow the creation of secure
transports, which will have additional implications for DPI.

>
>                       Harald
>
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>

--00163630e87191909e04993424e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thu, Jan 6, 2011 at 12:54 PM, Harald =
Alvestrand <ha=
rald@alvestrand.no> wrote:



On 01/06/11 20:18, Henry Sinnreich wrote:



Okay "direct flows of non-RTP application data" goes beyond scope=
 creep;

to satisfy this completely, we are talking an end-point-to-end-point tunnel=
,

which will run afoul of a lot of folks who dearly love packet inspection.


Why should the IETF and W3C abide by the folks who love deep packet

inspection? I would like to see some IESG guidance here, since it is

contrary to Internet and to the Web. Break of privacy, etc.



To accelerate clarity here, what does Harald and people on the list think?<=
br>


My personal opinion:



At the workshop, several use cases were identified where stuff that is not =
audio or video needed to be communicated from one browser to another quickl=
y enough that relaying via backend web server(s) is problematic - the canon=
ical poster child is the movement of bullets in a first-person shooter game=
, but there are other cases; I think Lisa mentioned that in Second Life, th=
e placement of audio sources in the stereo field needs to be communicated r=
easonably synchronously with the sound itself.





I am hesitant to rule point-to-point traffic that isn't audio or video =
out of scope, given the discussion at the workshop; certainly, given the RA=
VEN RFC (RFC 2804), I do not want to rule it out of scope because it's =
hard to write packet inspection state machines that can tell what's goi=
ng on here.




Right. The thinking was that since we need=
 to do a fair amount of work to allow audio and video to be exchanged safel=
y and reliably peer-to-peer, we should allow web applications (with some li=
mits) to use this transport mechanism for exchanging their own application =
data.=C2=A0




The plan also is to be able to leverage DTLS to allow t=
he creation of secure transports, which will have additional implications f=
or DPI.





 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 Harald




_______________________________________________

RTC-Web mailing list

RTC-Web@alvestra=
nd.no

http://www.alvestrand.no/mailman/listinfo/rtc-web





--00163630e87191909e04993424e4--

From juberti@google.com  Thu Jan  6 13:30:52 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0162B3A6F5D for ; Thu,  6 Jan 2011 13:30:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level: 
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSMwUnEGUIGD for ; Thu,  6 Jan 2011 13:30:51 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8CFB63A6D03 for ; Thu,  6 Jan 2011 13:30:50 -0800 (PST)
Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p06LWutF020884 for ; Thu, 6 Jan 2011 13:32:56 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294349576; bh=B7pWKC1qem9Thppz6loUdyK3m0k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=jqOb1hMDXoTOBfk3+oa2gmzTZiP8KT7wfDH2wkDT1C0q5BtKz+WYpNNldA0F7glnw b2qEGRzXfpYd7I3Pd4QOg==
Received: from qwk4 (qwk4.prod.google.com [10.241.195.132]) by wpaz9.hot.corp.google.com with ESMTP id p06LU1a1014525 for ; Thu, 6 Jan 2011 13:32:55 -0800
Received: by qwk4 with SMTP id 4so18306748qwk.32 for ; Thu, 06 Jan 2011 13:32:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=M/pBT5r+A5lxGoH12xRYksgBTY7PHwi2sAG6BsGxVYk=; b=ZQ/3TCJmu+VSwoPg6UiJxVBAbqW+9GtYKeREqb1faScjciIagDhBgFZ51HtnktC79C E6QZ3pOzxoU5VKSPfvRQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=NcCNX7WY9t7pSbj9WiTeFbVznT1hHpKgztZzyRgCwzgKk0aztGbYJRRM25WSwulg6X mxskWi34Inuroh+nYSfw==
Received: by 10.229.98.141 with SMTP id q13mr17764641qcn.151.1294349574688; Thu, 06 Jan 2011 13:32:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.135.9 with HTTP; Thu, 6 Jan 2011 13:32:34 -0800 (PST)
In-Reply-To: <4D25E1F8.2000802@alvestrand.no>
References:  <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com>   <4D201584.9040007@alvestrand.no>  <4D25E1F8.2000802@alvestrand.no>
From: Justin Uberti 
Date: Thu, 6 Jan 2011 13:32:34 -0800
Message-ID: 
To: Harald Alvestrand 
Content-Type: multipart/alternative; boundary=0016364ee1389d50960499343e77
X-System-Of-Record: true
Cc: rtc-web@alvestrand.no, dispatch@ietf.org, Markus.Isomaki@nokia.com
Subject: Re: [dispatch] [RTW] Comments on draft-alvestrand-dispatch-rtcweb-datagram
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 21:30:52 -0000

--0016364ee1389d50960499343e77
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 6, 2011 at 7:38 AM, Harald Alvestrand wrote:

>  On 01/06/11 08:05, Justin Uberti wrote:
>
>
>> Background: I had a discussion with a coworker who wanted to have a single
>> API to both streaming and datagram service; I believe it makes more sense to
>> define an API to a datagram service and an API to a streaming service
>> separately - the big argument for PseudoTCP is the client-to-client
>> connection case, where one often finds that UDP works and TCP doesn't.
>>
>
>  I had been thinking the datagram and streaming services should use a
> single API - much of the API ends up being the same, and that's how BSD
> sockets work. There are a few differences for streaming services, but they
> are mostly (entirely?) additive (flow control being the main one).
>
>
> The huge difference is that a streaming API gives you a sequence of bytes,
> in strict order, while a datagram API gives you a (not necessarily ordered)
> sequence of datagrams. Each datagram is guaranteed to be treated as an unit,
> but order is not preserved. There is no guarantee about block boundaries in
> a stream (you have to create them yourself if you want them), but order is
> strictly preserved.
>
> For most of the rest of the functions, the APIs can (and should) be the
> same, but the sending and reception of data is different.
>

Sure, but that doesn't seem like something the API has to worry about, other
than to allow the mode to be specified (datagram or streaming) when the
transport is created. For example, BSD sockets use the same APIs for stream
and datagram operations; send and recv each take a pointer and a length,
although the semantics are slightly different. (Note that sendto and
recvfrom also exist in BSD sockets, but aren't relevant in this case, where
the destination is fixed as a result of the ICE process).

>
>                       Harald
>
>
>

--0016364ee1389d50960499343e77
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thu, Jan 6, 2011 at 7:38 AM, Harald A=
lvestrand <har=
ald@alvestrand.no> wrote:




 =20
   =20
 =20
  

    On 01/06/11 08:05, Justin Uberti wrote:

    

      

        

          

          Background: I had a discussion with a coworker who wanted to
          have a single API to both streaming and datagram service; I
          believe it makes more sense to define an API to a datagram
          service and an API to a streaming service separately - the big
          argument for PseudoTCP is the client-to-client connection
          case, where one often finds that UDP works and TCP doesn't.
        

        


        

        
I had been thinking the datagram and streaming services
          should use a single API - much of the API ends up being the
          same, and that's how BSD sockets work. There are a few
          differences for streaming services, but they are mostly
          (entirely?) additive (flow control being the main one).

        

      

    

    

    The huge difference is that a streaming API gives you a sequence of
    bytes, in strict order, while a datagram API gives you a (not
    necessarily ordered) sequence of datagrams. Each datagram is
    guaranteed to be treated as an unit, but order is not preserved.
    There is no guarantee about block boundaries in a stream (you have
    to create them yourself if you want them), but order is strictly
    preserved.

    

    For most of the rest of the functions, the APIs can (and should) be
    the same, but the sending and reception of data is different.
=


Sure, but that doesn't seem like somet=
hing the API has to worry about, other than to allow the mode to be specifi=
ed (datagram or streaming) when the transport is created. For example, BSD =
sockets use the same APIs for stream and datagram operations; send and recv=
 each take a pointer and a length, although the semantics are slightly diff=
erent.=C2=A0(Note that sendto and recvfrom also exist in BSD sockets, but a=
ren't relevant in this case, where the destination is fixed as a result=
 of the ICE process).=C2=A0




    

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Harald

    

    

  






--0016364ee1389d50960499343e77--

From rbarnes@bbn.com  Thu Jan  6 13:39:17 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410F93A6F19 for ; Thu,  6 Jan 2011 13:39:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.732
X-Spam-Level: 
X-Spam-Status: No, score=-102.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFk9mMOUhQLi for ; Thu,  6 Jan 2011 13:39:16 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E92233A6C78 for ; Thu,  6 Jan 2011 13:39:15 -0800 (PST)
Received: from [192.1.255.181] (port=51142 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PaxaC-000IeQ-8e; Thu, 06 Jan 2011 16:41:20 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" 
In-Reply-To: <04BD8059-3B89-4F31-88CA-70F4D83ED553@americafree.tv>
Date: Thu, 6 Jan 2011 16:41:18 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <76C27DF8-52D0-47A5-A9D3-C4511D3250AE@bbn.com>
References: <4D25AE32.1020205@alvestrand.no>   <04BD8059-3B89-4F31-88CA-70F4D83ED553@americafree.tv>
To: Marshall Eubanks 
X-Mailer: Apple Mail (2.1082)
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" , Justin Uberti 
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 21:39:17 -0000

+1 to WEBTIME

Succinct, topical, and memorable.
(Unless someone thinks it's web-NTP or something...)

--Richard


On Jan 6, 2011, at 3:47 PM, Marshall Eubanks wrote:

>=20
> On Jan 6, 2011, at 1:42 PM, Justin Uberti wrote:
>=20
>>=20
>>=20
>> On Thu, Jan 6, 2011 at 8:47 AM, Marshall Eubanks  =
wrote:
>>=20
>> On Jan 6, 2011, at 6:57 AM, Harald Alvestrand wrote:
>>=20
>>> This activity remains nameless.
>>> The requirements for a name are:
>>>=20
>>> - It should be cute
>>> - It should be easy to remember
>>> - It should be easy to associate with the activity
>>>=20
>>> If it's also somewhat meaningful, that's a nice benefit.
>>> The boring choices include:
>>>=20
>>> - RTCWEB
>>> - WEBRTC
>>=20
>> Here is my proposal, not yet used in the IETF :
>>=20
>> REALTIME
>>=20
>> or, WREALTIME (silent W for 'web')
>>=20
>=20
> Or, if REALTIME is too general
>=20
> WEBTIME
>=20
> Marshall
>=20
>>=20
>>=20
>> Marshall
>>=20
>>>=20
>>> There are many others out there. I'll try to keep track of =
suggestions on a page at the RTCWeb website (rtc-web.alvestrand.no), and =
we'll find a way to decide after a few suggestions have been made.
>>> Let the creativity flow!
>>>=20
>>>             Harald
>>>=20
>>> _______________________________________________
>>> RTC-Web mailing list
>>> RTC-Web@alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>=20
>>=20
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web@alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From ted.ietf@gmail.com  Thu Jan  6 13:58:18 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FF93A6F48 for ; Thu,  6 Jan 2011 13:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.141
X-Spam-Level: 
X-Spam-Status: No, score=-3.141 tagged_above=-999 required=5 tests=[AWL=0.458,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94bkayKzKVu4 for ; Thu,  6 Jan 2011 13:58:17 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 359D23A6CFB for ; Thu,  6 Jan 2011 13:58:17 -0800 (PST)
Received: by qwi2 with SMTP id 2so1420118qwi.31 for ; Thu, 06 Jan 2011 14:00:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IohObUeXw+RViklNB3PpfCh1Aaw6HoxWlJKTxo3I+TY=; b=ob/o92wZh3yrfjYi51S5VH88TafQ7iaoLdGV7CPP3pS0XkAXYQahw2WusIi3ozhjPb T6Si6QyP79R1ferakGk4/bEpj8oUwtA9ZJUJt5OTiEvHnIoj8RW0n03XiCbaEkh6WwrS zLPqFsDk/nKdkfMDTGv+j4GT5mRX0T24eJ4Ng=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tPsutseItnKA7ls8ggxL/fx449dDY0zi+lDt/btnJR7ihygFjp7zEOlx5KlAKaIXq4 Je131W7UU2rZeMAKUS+H+y1lYPE9/ENd7aZz+GKUVDf3SsBHU9Ipx1sXPu8cn1bDqM0J vP8zhrOOS26WH2SAPhbKdfi4cB6G7NI+dkefY=
MIME-Version: 1.0
Received: by 10.229.96.132 with SMTP id h4mr21885672qcn.41.1294351223278; Thu, 06 Jan 2011 14:00:23 -0800 (PST)
Received: by 10.229.230.138 with HTTP; Thu, 6 Jan 2011 14:00:23 -0800 (PST)
In-Reply-To: 
References:  <4D262C15.2080702@alvestrand.no> 
Date: Thu, 6 Jan 2011 14:00:23 -0800
Message-ID: 
From: Ted Hardie 
To: Justin Uberti 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] dearly love packet inspection
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 21:58:18 -0000

On Thu, Jan 6, 2011 at 1:25 PM, Justin Uberti  wrote:

> Right. The thinking was that since we need to do a fair amount of work to
> allow audio and video to be exchanged safely and reliably peer-to-peer, w=
e
> should allow web applications (with some limits) to use this transport
> mechanism for exchanging their own application data.

>From a practical perspective, once you say "application data", the ability
to limit this seems to approach zero pretty quickly.  Even ignoring the
network-based firewall, doesn't this now require me to have a browser-based
firewall, to express my policies for what traffic I permit over this?

> The plan also is to be able to leverage DTLS to allow the creation of sec=
ure
> transports, which will have additional implications for DPI.

Agreed.  More importantly, I think that reinforces the idea that this is no=
t
a simple add-on to audio/video functionality.  As I argued in
draft-hardie-mdtls-session,
you are really creating a multi-flow session layer.  I personally
think that's a fine
thing, but it is not an adjunct to a charter-it's the top-line bullet
item in my view.

regards,

Ted

PS.  As an aside, both Jake and I have since left Panasonic and the
project mentioned in
the draft cited above.  I do not believe that the sponsor lab will release =
the
code created for it at this time so the discussion I had with some
folks on that in Beijing
will likely need to take other paths.


>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harald
>>
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web@alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
>

From hmmr@cisco.com  Thu Jan  6 14:04:31 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E213A6D1A for ; Thu,  6 Jan 2011 14:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.64
X-Spam-Level: 
X-Spam-Status: No, score=-10.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUqaln1Mm+uM for ; Thu,  6 Jan 2011 14:04:29 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B5DAE3A6F48 for ; Thu,  6 Jan 2011 14:04:29 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEANPLJU2tJXG8/2dsb2JhbACkH3OlQpgohUwEhGeJRQ
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2011 22:06:36 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p06M6ZBa029137;  Thu, 6 Jan 2011 22:06:35 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 6 Jan 2011 16:06:35 -0600
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 6 Jan 2011 16:06:34 -0600
Message-ID: 
In-Reply-To: <76C27DF8-52D0-47A5-A9D3-C4511D3250AE@bbn.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] [RTW] Name discussion: What is the name of the WGthat does the RTC-Web stuff?
Thread-Index: Acut6ny02Y37x9uqSbSKVRSmDkQ0HQAA3fSA
References: <4D25AE32.1020205@alvestrand.no><04BD8059-3B89-4F31-88CA-70F4D83ED553@americafree.tv> <76C27DF8-52D0-47A5-A9D3-C4511D3250AE@bbn.com>
From: "Mike Hammer (hmmr)" 
To: "Richard L. Barnes" , "Marshall Eubanks" 
X-OriginalArrivalTime: 06 Jan 2011 22:06:35.0773 (UTC) FILETIME=[FC0C9AD0:01CBADED]
Cc: Harald Alvestrand , rtc-web@alvestrand.no, dispatch@ietf.org, Justin Uberti 
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WGthat does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 22:04:31 -0000

WEBFLOWS ?


-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Richard L. Barnes
Sent: Thursday, January 06, 2011 4:41 PM
To: Marshall Eubanks
Cc: Harald Alvestrand; rtc-web@alvestrand.no; dispatch@ietf.org; Justin
Uberti
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the
WGthat does the RTC-Web stuff?

+1 to WEBTIME

Succinct, topical, and memorable.
(Unless someone thinks it's web-NTP or something...)

--Richard


On Jan 6, 2011, at 3:47 PM, Marshall Eubanks wrote:

>=20
> On Jan 6, 2011, at 1:42 PM, Justin Uberti wrote:
>=20
>>=20
>>=20
>> On Thu, Jan 6, 2011 at 8:47 AM, Marshall Eubanks 
wrote:
>>=20
>> On Jan 6, 2011, at 6:57 AM, Harald Alvestrand wrote:
>>=20
>>> This activity remains nameless.
>>> The requirements for a name are:
>>>=20
>>> - It should be cute
>>> - It should be easy to remember
>>> - It should be easy to associate with the activity
>>>=20
>>> If it's also somewhat meaningful, that's a nice benefit.
>>> The boring choices include:
>>>=20
>>> - RTCWEB
>>> - WEBRTC
>>=20
>> Here is my proposal, not yet used in the IETF :
>>=20
>> REALTIME
>>=20
>> or, WREALTIME (silent W for 'web')
>>=20
>=20
> Or, if REALTIME is too general
>=20
> WEBTIME
>=20
> Marshall
>=20
>>=20
>>=20
>> Marshall
>>=20
>>>=20
>>> There are many others out there. I'll try to keep track of
suggestions on a page at the RTCWeb website (rtc-web.alvestrand.no), and
we'll find a way to decide after a few suggestions have been made.
>>> Let the creativity flow!
>>>=20
>>>             Harald
>>>=20
>>> _______________________________________________
>>> RTC-Web mailing list
>>> RTC-Web@alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>>=20
>>=20
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web@alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From tterriberry@mozilla.com  Thu Jan  6 14:13:45 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6E73A6D1A for ; Thu,  6 Jan 2011 14:13:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level: 
X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vER9SZ1al-yQ for ; Thu,  6 Jan 2011 14:13:45 -0800 (PST)
Received: from mxip1i.isis.unc.edu (mxip1i.isis.unc.edu [152.2.0.74]) by core3.amsl.com (Postfix) with ESMTP id E06A93A6B9E for ; Thu,  6 Jan 2011 14:13:44 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFALLNJU2sGgRS/2dsb2JhbACjTIFGvWaFTASEZ4kzDA
X-IronPort-AV: E=Sophos;i="4.60,285,1291611600"; d="scan'208";a="63669858"
Received: from mr1a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.82]) by mxip1o.isis.unc.edu with ESMTP; 06 Jan 2011 17:15:49 -0500
Received: from [192.168.11.4] (pool-71-114-26-50.washdc.dsl-w.verizon.net [71.114.26.50]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p06MFlJk015873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2011 17:15:49 -0500 (EST)
Message-ID: <4D263F13.7040907@mozilla.com>
Date: Thu, 06 Jan 2011 14:15:47 -0800
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10
MIME-Version: 1.0
References: <4D25AE32.1020205@alvestrand.no>			<04BD8059-3B89-4F31-88CA-70F4D83ED553@americafree.tv> <76C27DF8-52D0-47A5-A9D3-C4511D3250AE@bbn.com>
In-Reply-To: <76C27DF8-52D0-47A5-A9D3-C4511D3250AE@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 22:13:45 -0000

> +1 to WEBTIME

This is probably too close to Apple's FaceTime. Unless that is a 
parallel you want to make intentionally. But if you don't, others will.

From harald@alvestrand.no  Thu Jan  6 14:25:52 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46013A6F29 for ; Thu,  6 Jan 2011 14:25:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.552
X-Spam-Level: 
X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19tQezxKRNrX for ; Thu,  6 Jan 2011 14:25:51 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 677483A6B9E for ; Thu,  6 Jan 2011 14:25:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D36C439E263; Thu,  6 Jan 2011 23:27:33 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwtWdtON5GvU; Thu,  6 Jan 2011 23:27:33 +0100 (CET)
Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6553439E04C; Thu,  6 Jan 2011 23:27:32 +0100 (CET)
Message-ID: <4D2641EB.6080505@alvestrand.no>
Date: Thu, 06 Jan 2011 23:27:55 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: Justin Uberti 
References:  <6EE0B7DD-614E-4A9E-98D3-16434A8A65A7@apple.com>   <4D201584.9040007@alvestrand.no>  <4D25E1F8.2000802@alvestrand.no> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050409060607090403040901"
Cc: rtc-web@alvestrand.no, dispatch@ietf.org, Markus.Isomaki@nokia.com
Subject: Re: [dispatch] [RTW] Comments on draft-alvestrand-dispatch-rtcweb-datagram
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 22:25:53 -0000

This is a multi-part message in MIME format.
--------------050409060607090403040901
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 01/06/11 22:32, Justin Uberti wrote:
>
>
> On Thu, Jan 6, 2011 at 7:38 AM, Harald Alvestrand 
> > wrote:
>
>     On 01/06/11 08:05, Justin Uberti wrote:
>>
>>
>>         Background: I had a discussion with a coworker who wanted to
>>         have a single API to both streaming and datagram service; I
>>         believe it makes more sense to define an API to a datagram
>>         service and an API to a streaming service separately - the
>>         big argument for PseudoTCP is the client-to-client connection
>>         case, where one often finds that UDP works and TCP doesn't.
>>
>>
>>     I had been thinking the datagram and streaming services should
>>     use a single API - much of the API ends up being the same, and
>>     that's how BSD sockets work. There are a few differences for
>>     streaming services, but they are mostly (entirely?) additive
>>     (flow control being the main one).
>
>     The huge difference is that a streaming API gives you a sequence
>     of bytes, in strict order, while a datagram API gives you a (not
>     necessarily ordered) sequence of datagrams. Each datagram is
>     guaranteed to be treated as an unit, but order is not preserved.
>     There is no guarantee about block boundaries in a stream (you have
>     to create them yourself if you want them), but order is strictly
>     preserved.
>
>     For most of the rest of the functions, the APIs can (and should)
>     be the same, but the sending and reception of data is different.
>
>
> Sure, but that doesn't seem like something the API has to worry about, 
> other than to allow the mode to be specified (datagram or streaming) 
> when the transport is created. For example, BSD sockets use the same 
> APIs for stream and datagram operations; send and recv each take a 
> pointer and a length, although the semantics are slightly 
> different. (Note that sendto and recvfrom also exist in BSD sockets, 
> but aren't relevant in this case, where the destination is fixed as a 
> result of the ICE process).
The semantics are a whole lot different; send(3 bytes) + send(3 bytes) 
on a streaming socket can get you a recv(6 bytes); send(3 bytes) + 
send(3 bytes) on a datagram socket gives you recv(3 bytes), twice. The 
fact that the BSD socket interface tries to hide this distinction is a 
weakness of BSD sockets. (My master's thesis work back in 1984 involved 
an email exchange with Jon Postel to verify the semantics of TCP wrt 
packet boundaries - it seems that it's been an argument within the ARPA 
community for quite some time before that, too).

The programmer has to be completely clear on whether packet boundaries 
will be preserved over the API or not. This is clearest when it's 
visible in the API.

                        Harald


--------------050409060607090403040901
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
    
  
  
    On 01/06/11 22:32, Justin Uberti wrote:
    


      

      
On Thu, Jan 6, 2011 at 7:38 AM, Harald
        Alvestrand <harald@alvestrand.no>
        wrote:

        

          

            
 On 01/06/11 08:05, Justin Uberti wrote:

              

                

                  
 

                    Background: I had a discussion with a coworker who
                    wanted to have a single API to both streaming and
                    datagram service; I believe it makes more sense to
                    define an API to a datagram service and an API to a
                    streaming service separately - the big argument for
                    PseudoTCP is the client-to-client connection case,
                    where one often finds that UDP works and TCP
                    doesn't.

                  

                  


                  

                  
I had been thinking the datagram and streaming
                    services should use a single API - much of the API
                    ends up being the same, and that's how BSD sockets
                    work. There are a few differences for streaming
                    services, but they are mostly (entirely?) additive
                    (flow control being the main one).

                  

                

              

              

            

            The huge difference is that a streaming API gives you a
            sequence of bytes, in strict order, while a datagram API
            gives you a (not necessarily ordered) sequence of datagrams.
            Each datagram is guaranteed to be treated as an unit, but
            order is not preserved. There is no guarantee about block
            boundaries in a stream (you have to create them yourself if
            you want them), but order is strictly preserved.

            

            For most of the rest of the functions, the APIs can (and
            should) be the same, but the sending and reception of data
            is different.

          

        

        


        

        
Sure, but that doesn't seem like something the API has to
          worry about, other than to allow the mode to be specified
          (datagram or streaming) when the transport is created. For
          example, BSD sockets use the same APIs for stream and datagram
          operations; send and recv each take a pointer and a length,
          although the semantics are slightly different. (Note that
          sendto and recvfrom also exist in BSD sockets, but aren't
          relevant in this case, where the destination is fixed as a
          result of the ICE process).

      

    

    The semantics are a whole lot different; send(3 bytes) + send(3
    bytes) on a streaming socket can get you a recv(6 bytes); send(3
    bytes) + send(3 bytes) on a datagram socket gives you recv(3 bytes),
    twice. The fact that the BSD socket interface tries to hide this
    distinction is a weakness of BSD sockets. (My master's thesis work
    back in 1984 involved an email exchange with Jon Postel to verify
    the semantics of TCP wrt packet boundaries - it seems that it's been
    an argument within the ARPA community for quite some time before
    that, too).

    

    The programmer has to be completely clear on whether packet
    boundaries will be preserved over the API or not. This is clearest
    when it's visible in the API.

    

                           Harald

    

  


--------------050409060607090403040901--

From juberti@google.com  Thu Jan  6 14:31:08 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0113A6F6B for ; Thu,  6 Jan 2011 14:31:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level: 
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLMEKnyXKH-m for ; Thu,  6 Jan 2011 14:31:07 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id D35493A6F79 for ; Thu,  6 Jan 2011 14:31:06 -0800 (PST)
Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p06MXCRB006469 for ; Thu, 6 Jan 2011 14:33:12 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294353192; bh=0XBTx6yIYaj9M66uachMM/21jJY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Dmebqo9G27HiLtGDRH7H4DxU9nCBu7prHsWIcp0lDhS4IgpIWK95M6roTsfO7yhx7 xQ38I+a36F/rupukWtQcg==
Received: from qyk1 (qyk1.prod.google.com [10.241.83.129]) by kpbe16.cbf.corp.google.com with ESMTP id p06MWQPJ014746 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 6 Jan 2011 14:33:10 -0800
Received: by qyk1 with SMTP id 1so19134404qyk.4 for ; Thu, 06 Jan 2011 14:33:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=KC7+2A7scokJEXwR/RvZDqpX51m66p1dH5Y+AI/xOes=; b=O+son9q8JSFB60BTf8s+5+KQRtWH10VgYdZWi7Ye5szmobtF6b94EP0Orm9CIm4Us/ TC0SqheHopGPppyleI+Q==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Ekow3cLsEUFIANGoA9rmVF98SJN/lw/3Whwhpn4jwFM9IX/5y5lksOFGmHQJnkL0x0 iLXAqVyLByYYGob4FG+A==
Received: by 10.229.98.141 with SMTP id q13mr17813972qcn.151.1294353190404; Thu, 06 Jan 2011 14:33:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.135.9 with HTTP; Thu, 6 Jan 2011 14:32:50 -0800 (PST)
In-Reply-To: 
References:  <4D262C15.2080702@alvestrand.no>  
From: Justin Uberti 
Date: Thu, 6 Jan 2011 14:32:50 -0800
Message-ID: 
To: Ted Hardie 
Content-Type: multipart/alternative; boundary=0016364ee13820c3840499351629
X-System-Of-Record: true
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] dearly love packet inspection
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 22:31:08 -0000

--0016364ee13820c3840499351629
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 6, 2011 at 2:00 PM, Ted Hardie  wrote:

> On Thu, Jan 6, 2011 at 1:25 PM, Justin Uberti  wrote:
>
> > Right. The thinking was that since we need to do a fair amount of work to
> > allow audio and video to be exchanged safely and reliably peer-to-peer,
> we
> > should allow web applications (with some limits) to use this transport
> > mechanism for exchanging their own application data.
>
> From a practical perspective, once you say "application data", the ability
> to limit this seems to approach zero pretty quickly.  Even ignoring the
> network-based firewall, doesn't this now require me to have a browser-based
> firewall, to express my policies for what traffic I permit over this?
>

The connection is limited by the browser same-origin policy, so the
application can only connect to places blessed by the application server,
similar to XmlHttpRequest. We don't worry about apps making XmlHttpRequest
over TLS, where there is little ability to control the data, and I think we
should try to think of these transports the same way.


> > The plan also is to be able to leverage DTLS to allow the creation of
> secure
> > transports, which will have additional implications for DPI.
>
> Agreed.  More importantly, I think that reinforces the idea that this is
> not
> a simple add-on to audio/video functionality.  As I argued in
> draft-hardie-mdtls-session,
> you are really creating a multi-flow session layer.  I personally
> think that's a fine
> thing, but it is not an adjunct to a charter-it's the top-line bullet
> item in my view.
>
> regards,
>
> Ted
>
> PS.  As an aside, both Jake and I have since left Panasonic and the
> project mentioned in
> the draft cited above.  I do not believe that the sponsor lab will release
> the
> code created for it at this time so the discussion I had with some
> folks on that in Beijing
> will likely need to take other paths.
>
>
> >>
> >>                       Harald
> >>
> >> _______________________________________________
> >> RTC-Web mailing list
> >> RTC-Web@alvestrand.no
> >> http://www.alvestrand.no/mailman/listinfo/rtc-web
> >
> >
>

--0016364ee13820c3840499351629
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thu, Jan 6, 2011 at 2:00 PM, Ted Hard=
ie <ted.ietf@gma=
il.com> wrote:



On Thu, Jan 6, 2011 at 1:25 PM, Justin Uberti <juberti@google.com> wrote:



> Right. The thinking was that since we need to do a fair amount of work=
 to

> allow audio and video to be exchanged safely and reliably peer-to-peer=
, we

> should allow web applications (with some limits) to use this transport=


> mechanism for exchanging their own application data.




From a practical perspective, once you say "application data&quo=
t;, the ability

to limit this seems to approach zero pretty quickly. =C2=A0Even ignoring th=
e

network-based firewall, doesn't this now require me to have a browser-b=
ased

firewall, to express my policies for what traffic I permit over this?

The connection is limited by the browser sam=
e-origin policy, so the application can only connect to places blessed by t=
he application server, similar to XmlHttpRequest. We don't worry about =
apps making XmlHttpRequest over TLS, where there is little ability to contr=
ol the data, and I think we should try to think of these transports the sam=
e way.








> The plan also is to be able to leverage DTLS to allow the creation of =
secure

> transports, which will have additional implications for DPI.




Agreed. =C2=A0More importantly, I think that reinforces the idea that=
 this is not

a simple add-on to audio/video functionality. =C2=A0As I argued in

draft-hardie-mdtls-session,

you are really creating a multi-flow session layer. =C2=A0I personally

think that's a fine

thing, but it is not an adjunct to a charter-it's the top-line bullet
item in my view.



regards,



Ted



PS. =C2=A0As an aside, both Jake and I have since left Panasonic and the
project mentioned in

the draft cited above. =C2=A0I do not believe that the sponsor lab will rel=
ease the

code created for it at this time so the discussion I had with some

folks on that in Beijing

will likely need to take other paths.






>>

>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Harald

>>

>> _______________________________________________

>> RTC-Web mailing list

>> RTC-Web@alvestrand.no=


>> http://www.alvestrand.no/mailman/listinfo/rtc-web

>

>





--0016364ee13820c3840499351629--

From stefan.lk.hakansson@ericsson.com  Thu Jan  6 14:35:19 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84183A6F6A for ; Thu,  6 Jan 2011 14:35:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm2UBBqrhv2o for ; Thu,  6 Jan 2011 14:35:18 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 00CB03A6F6B for ; Thu,  6 Jan 2011 14:35:17 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-88-4d26442450ad
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FF.F5.23694.424462D4; Thu,  6 Jan 2011 23:37:24 +0100 (CET)
Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.190]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 6 Jan 2011 23:37:24 +0100
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= 
To: "DRAGE, Keith (Keith)" , Harald Alvestrand , "'dispatch@ietf.org'" , "rtc-web@alvestrand.no" 
Date: Thu, 6 Jan 2011 23:37:22 +0100
Thread-Topic: [RTW] [dispatch] Name discussion: What is the name of the WG that does the RTC-Web stuff?
Thread-Index: AcutmPCXslHC3aTNRvCeVPcmAv/52QAD01aAABJ+M5A=
Message-ID: 
References: <4D25AE32.1020205@alvestrand.no> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 22:35:19 -0000

+1

//Stefan=20

> -----Original Message-----
> From: rtc-web-bounces@alvestrand.no=20
> [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of DRAGE,=20
> Keith (Keith)
> Sent: den 6 januari 2011 14:50
> To: Harald Alvestrand; 'dispatch@ietf.org'; rtc-web@alvestrand.no
> Subject: Re: [RTW] [dispatch] Name discussion: What is the=20
> name of the WG that does the RTC-Web stuff?
>=20
> Please stick to boring.
>=20
> I have the greatest difficulty in remembering what some=20
> current RAI WG are about when starting from the acronym.
>=20
> So I would place your requirements in reverse order for a=20
> prioritised list.
>=20
> Keith
>=20
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org
> > [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand
> > Sent: Thursday, January 06, 2011 11:58 AM
> > To: 'dispatch@ietf.org'; rtc-web@alvestrand.no
> > Subject: [dispatch] Name discussion: What is the name of=20
> the WG that=20
> > does the RTC-Web stuff?
> >=20
> > This activity remains nameless.
> > The requirements for a name are:
> >=20
> > - It should be cute
> > - It should be easy to remember
> > - It should be easy to associate with the activity
> >=20
> > If it's also somewhat meaningful, that's a nice benefit.
> > The boring choices include:
> >=20
> > - RTCWEB
> > - WEBRTC
> >=20
> > There are many others out there. I'll try to keep track of=20
> suggestions=20
> > on a page at the RTCWeb website (rtc-web.alvestrand.no), and we'll=20
> > find a way to decide after a few suggestions have been made.
> > Let the creativity flow!
> >=20
> >                Harald
> >=20
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >=20
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
> =

From juberti@google.com  Thu Jan  6 14:43:16 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B0C3A6F6A for ; Thu,  6 Jan 2011 14:43:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.376
X-Spam-Level: 
X-Spam-Status: No, score=-103.376 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p90kYxwjZKQ7 for ; Thu,  6 Jan 2011 14:43:15 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 334A43A6D23 for ; Thu,  6 Jan 2011 14:43:15 -0800 (PST)
Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p06MjLhJ019050 for ; Thu, 6 Jan 2011 14:45:21 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294353921; bh=sxIDXikh8NDNLAKV/80WPH+AVic=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=FOnIqfMQAURdivfhw9O4SePCyltbbEB5GD4uA68mY4UeFEcHtIMVTaKtXnnjo/gdi UByQSvpflhHYVCkW3l+SA==
Received: from qwh6 (qwh6.prod.google.com [10.241.194.198]) by wpaz9.hot.corp.google.com with ESMTP id p06MiwIZ011525 for ; Thu, 6 Jan 2011 14:45:20 -0800
Received: by qwh6 with SMTP id 6so18922963qwh.7 for ; Thu, 06 Jan 2011 14:45:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=zU4Qnk6JNsFgtd+T2adEO+0eTTvAWUrvZcH3SlUj3xI=; b=K5K941bTQH730Tb0JOIFtVHQmQurRMZBq1zcZYO/fGs4PV73kINzSICd9Is4ypKhg1 maWyQAOqswJa9Q8PYuSw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=m8bOrKYCzc23MCYeWyc17JjSpbFzpNocIjsGhjhwyhR3eZ3jjii0ogLts2T/6BlJ4v zFxeOWDF2jEcMqnHWCtw==
Received: by 10.229.223.139 with SMTP id ik11mr21358843qcb.265.1294353920416;  Thu, 06 Jan 2011 14:45:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.135.9 with HTTP; Thu, 6 Jan 2011 14:45:00 -0800 (PST)
In-Reply-To: <4D263F13.7040907@mozilla.com>
References: <4D25AE32.1020205@alvestrand.no>   <04BD8059-3B89-4F31-88CA-70F4D83ED553@americafree.tv> <76C27DF8-52D0-47A5-A9D3-C4511D3250AE@bbn.com> <4D263F13.7040907@mozilla.com>
From: Justin Uberti 
Date: Thu, 6 Jan 2011 14:45:00 -0800
Message-ID: 
To: "Timothy B. Terriberry" 
Content-Type: multipart/alternative; boundary=0016e64f4588a3de4a0499354175
X-System-Of-Record: true
Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 22:43:16 -0000

--0016e64f4588a3de4a0499354175
Content-Type: text/plain; charset=UTF-8

BRAVO = Browser Realtime Audio and VideO?

On Thu, Jan 6, 2011 at 2:15 PM, Timothy B. Terriberry <
tterriberry@mozilla.com> wrote:

> +1 to WEBTIME
>>
>
> This is probably too close to Apple's FaceTime. Unless that is a parallel
> you want to make intentionally. But if you don't, others will.
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>

--0016e64f4588a3de4a0499354175
Content-Type: text/html; charset=UTF-8

BRAVO = Browser Realtime Audio and VideO?

On Thu, Jan 6, 2011 at 2:15 PM, Timothy B. Terriberry <tterriberry@mozilla.com> wrote:




+1 to WEBTIME





This is probably too close to Apple's FaceTime. Unless that is a parallel you want to make intentionally. But if you don't, others will.


_______________________________________________

RTC-Web mailing list

RTC-Web@alvestrand.no

http://www.alvestrand.no/mailman/listinfo/rtc-web





--0016e64f4588a3de4a0499354175--

From rbarnes@bbn.com  Thu Jan  6 15:07:40 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8683A6F75 for ; Thu,  6 Jan 2011 15:07:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.726
X-Spam-Level: 
X-Spam-Status: No, score=-102.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZ4qCUL+j7jp for ; Thu,  6 Jan 2011 15:07:39 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 17F933A6D23 for ; Thu,  6 Jan 2011 15:07:39 -0800 (PST)
Received: from [192.1.255.181] (port=51816 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Payxd-000I2G-LJ; Thu, 06 Jan 2011 18:09:37 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" 
In-Reply-To: 
Date: Thu, 6 Jan 2011 18:09:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2ECE2C8F-0708-4CB2-95AE-A1569AB28B42@bbn.com>
References: <4D25AE32.1020205@alvestrand.no>   <04BD8059-3B89-4F31-88CA-70F4D83ED553@americafree.tv> <76C27DF8-52D0-47A5-A9D3-C4511D3250AE@bbn.com> <4D263F13.7040907@mozilla.com> 
To: Justin Uberti 
X-Mailer: Apple Mail (2.1082)
Cc: "Timothy B. Terriberry" , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Jan 2011 23:07:40 -0000

+1 now transferred to BRAVO



On Jan 6, 2011, at 5:45 PM, Justin Uberti wrote:

> BRAVO =3D Browser Realtime Audio and VideO?
>=20
> On Thu, Jan 6, 2011 at 2:15 PM, Timothy B. Terriberry =
 wrote:
> +1 to WEBTIME
>=20
> This is probably too close to Apple's FaceTime. Unless that is a =
parallel you want to make intentionally. But if you don't, others will.
>=20
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>=20
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web


From singer@apple.com  Thu Jan  6 16:12:21 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318843A6F41 for ; Thu,  6 Jan 2011 16:12:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.339
X-Spam-Level: 
X-Spam-Status: No, score=-106.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YZ8diL6VX9k for ; Thu,  6 Jan 2011 16:12:20 -0800 (PST)
Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 996573A6F3E for ; Thu,  6 Jan 2011 16:12:20 -0800 (PST)
Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 97AFBC9D0669; Thu,  6 Jan 2011 16:14:27 -0800 (PST)
X-AuditID: 1180711d-b7c30ae0000055b4-00-4d265ae3dd62
Received: from singda.apple.com (singda.apple.com [17.197.20.4]) by relay13.apple.com (Apple SCV relay) with SMTP id B6.DA.21940.3EA562D4; Thu,  6 Jan 2011 16:14:27 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: David Singer 
In-Reply-To: <2ECE2C8F-0708-4CB2-95AE-A1569AB28B42@bbn.com>
Date: Thu, 6 Jan 2011 16:14:27 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4D25AE32.1020205@alvestrand.no>   <04BD8059-3B89-4F31-88CA-70F4D83ED553@americafree.tv> <76C27DF8-52D0-47A5-A9D3-C4511D3250AE@bbn.com> <4D263F13.7040907@mozilla.com>  <2ECE2C8F-0708-4CB2-95AE-A1569AB28B42@bbn.com>
To: rtc-web@alvestrand.no, dispatch@ietf.org
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG	that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 00:12:21 -0000

we now know it as RTCWEB, and I don't really see the need for a name =
change, and I certainly don't want something cute but un-memorable.  So =
I prefer RTCWEB...(I also prefer less email on the subject, but, =
whatever).

David Singer
Multimedia and Software Standards, Apple Inc.


From singer@apple.com  Thu Jan  6 16:20:17 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A8D3A6F81 for ; Thu,  6 Jan 2011 16:20:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.383
X-Spam-Level: 
X-Spam-Status: No, score=-106.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNTADZYxpsKL for ; Thu,  6 Jan 2011 16:20:15 -0800 (PST)
Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 5ADFB3A6F80 for ; Thu,  6 Jan 2011 16:20:15 -0800 (PST)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 69CBFC537428; Thu,  6 Jan 2011 16:22:22 -0800 (PST)
X-AuditID: 11807137-b7bfaae000004d31-7d-4d265cbe269e
Received: from singda.apple.com (singda.apple.com [17.197.20.4]) by relay16.apple.com (Apple SCV relay) with SMTP id FB.E8.19761.EBC562D4; Thu,  6 Jan 2011 16:22:22 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: David Singer 
In-Reply-To: <9AFF6B7A-11DF-4111-B0E7-D4BE6C454944@americafree.tv>
Date: Thu, 6 Jan 2011 16:22:21 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4D25AD41.7060306@alvestrand.no> <9AFF6B7A-11DF-4111-B0E7-D4BE6C454944@americafree.tv>
To: Marshall Eubanks 
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" 
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known	as "RTC-WEB at IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 00:20:17 -0000

On Jan 6, 2011, at 4:49 , Marshall Eubanks wrote:

>=20
> On Jan 6, 2011, at 6:53 AM, Harald Alvestrand wrote:
>=20
>> This is the first of 3 messages going to the DISPATCH list (in the =
hope of keeping discussions somewhat organized).
>>=20
>> This is the draft of a charter for an IETF working group to consider =
the subject area of "Real time communication in the Web browser =
platform". This is one of a paired set of activities, the other one =
being a W3C activity (either within an existing WG or in a new WG) that =
defines APIs to this functionality.
>>=20
>> The two other messages will contain the W3C proposed charter and a =
kickoff for what's usually the most distracting topic in any such =
discussion: The name of the group.
>=20
> Dear Harold;
>=20
> Just to be clear, your intent is to have simultaneously a W3C WG and =
an IETF WG on this issue ?=20
>=20
> Shouldn't there be some text about coordination between these efforts =
? I don't see much discussion in either=20
> charter as to which is gating, but it seems to me that the W3C work =
would have to be gated on the IETF work. Isn't there a danger that
> the W3C WG might start building on early solutions discussed in the =
IETF, only to have the IETF WG decide to go in a different direction ?=20=

>=20

Hi=20

I'm sorry if this has already been said, but I am pretty sure that the =
W3C's work should provide a pretty general framework into which all =
sorts of instantiations (protocols and implementations) can be fit.  An =
example might be "a URL that addresses the remote end goes here" and a =
URL has a protocol part (before the colon) and an 'address' part (after =
it).  Sure, the first protocol instantiated (in definition and code) =
should be the stuff worked on with the IETF, but the architecture should =
not preclude others.  I am sure there will be back and forth, and it's =
important that the functional division into pieces, and the =
architectural division between 'markup' (w3c) and 'protocol' (ietf) be =
agreed, and that the final pieces do, in fact work together.

But I think it very important that we see at least two layers of =
definition here: modularization, framework, and so on, which is pretty =
general;  and specific modules that fit into that framework and make our =
first working system, which need to be very specific.

David Singer
Multimedia and Software Standards, Apple Inc.


From ted.ietf@gmail.com  Thu Jan  6 17:04:46 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5343A6F6B for ; Thu,  6 Jan 2011 17:04:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.155
X-Spam-Level: 
X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[AWL=0.444,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQYPv2nEab6t for ; Thu,  6 Jan 2011 17:04:45 -0800 (PST)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id E6FBE3A6DD1 for ; Thu,  6 Jan 2011 17:04:44 -0800 (PST)
Received: by qyj19 with SMTP id 19so18368178qyj.10 for ; Thu, 06 Jan 2011 17:06:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=is3ObxKkZr6xiQHQCSC3QLvJl70EDet6QLWlRglz2aQ=; b=Xi/0nQV7vpRrhgkpdPx3Y4Yh+bttbGdrNo3YIXV+mpa6v/s5FPVpyo7m18HFZNara/ AwyuDJIjKO1uhEHQxoJIOiays8j9H6P7pnxkeReCc3xSSBoISZf3X5QWizW3fNJLrTHg S1h1Z19sppgqkDJGhuF7CamsuL6bOdnKDh7XQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uGY9D7ICz3rEG1ZEnxWFIx6AOiaki6Y2n86WuVhZKrCVxkI9sBGiZMwqkcWahkM0qg phjU5BFqXTfZzbD0tTBj3l/irquRqHSdN8owd5fG78M9zHV7EM1CB/Y+as5xHMV2PYab A+YP8FZr5kB3IRt4IQjGBdBscbELLQRvaKy/A=
MIME-Version: 1.0
Received: by 10.229.189.20 with SMTP id dc20mr21480899qcb.231.1294362410176; Thu, 06 Jan 2011 17:06:50 -0800 (PST)
Received: by 10.229.230.138 with HTTP; Thu, 6 Jan 2011 17:06:50 -0800 (PST)
In-Reply-To: 
References:  <4D262C15.2080702@alvestrand.no>   
Date: Thu, 6 Jan 2011 17:06:50 -0800
Message-ID: 
From: Ted Hardie 
To: Justin Uberti 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] dearly love packet inspection
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 01:04:46 -0000

On Thu, Jan 6, 2011 at 2:32 PM, Justin Uberti  wrote:
>
>
> The connection is limited by the browser same-origin policy, so the
> application can only connect to places blessed by the application server,
> similar to XmlHttpRequest. We don't worry about apps making XmlHttpReques=
t
> over TLS, where there is little ability to control the data, and I think =
we
> should try to think of these transports the same way.

First, I'm not sure that everyone has the same view "of not worry" here.
Second, I'm really not sure that the threat model is the same.  If I have
an open pipe between any two peers which can carry any traffic which
fits over DTLS, the situation is a bit different from that where https
is running through to a server.  And the chances that someone terminates
and re-originates the TLS flow seems to me to go up in some common cases
if it has this characteristic.

But I think the charter comment for now is that this is a major chunk of wo=
rk,
and that it has considerations outside those for audio and video.  To me,
that means it needs to be called out (either in its own documents or in a
re-charter), so that it doesn't gate the base functionality.

Please remember as well that just because the initiating use case for this
protocol work is browser based there is no reason to presume that it
will stay browser based for all time.  Even in this framework a
browser-initiated DTLS
flow could be handed off to another "helper" app.

Again, I think this is potentially a lot of work.  That doesn't mean I
think it is
bad work; I think it means it has to be scoped appropriately.

regards,

Ted
>>
>> > The plan also is to be able to leverage DTLS to allow the creation of
>> > secure
>> > transports, which will have additional implications for DPI.
>>
>> Agreed. =A0More importantly, I think that reinforces the idea that this =
is
>> not
>> a simple add-on to audio/video functionality. =A0As I argued in
>> draft-hardie-mdtls-session,
>> you are really creating a multi-flow session layer. =A0I personally
>> think that's a fine
>> thing, but it is not an adjunct to a charter-it's the top-line bullet
>> item in my view.
>>
>> regards,
>>
>> Ted
>>
>> PS. =A0As an aside, both Jake and I have since left Panasonic and the
>> project mentioned in
>> the draft cited above. =A0I do not believe that the sponsor lab will rel=
ease
>> the
>> code created for it at this time so the discussion I had with some
>> folks on that in Beijing
>> will likely need to take other paths.
>>
>>
>> >>
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harald
>> >>
>> >> _______________________________________________
>> >> RTC-Web mailing list
>> >> RTC-Web@alvestrand.no
>> >> http://www.alvestrand.no/mailman/listinfo/rtc-web
>> >
>> >
>
>

From john.elwell@siemens-enterprise.com  Fri Jan  7 01:36:32 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1143A67F9 for ; Fri,  7 Jan 2011 01:36:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nphMKFmjD82X for ; Fri,  7 Jan 2011 01:36:27 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 018DC3A67F6 for ; Fri,  7 Jan 2011 01:36:26 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2925297; Fri, 7 Jan 2011 10:38:32 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id B511923F028E; Fri,  7 Jan 2011 10:38:32 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 7 Jan 2011 10:38:32 +0100
From: "Elwell, John" 
To: Harald Alvestrand , "'dispatch@ietf.org'" 
Date: Fri, 7 Jan 2011 10:38:30 +0100
Thread-Topic: [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at	IETF"
Thread-Index: AcutmF48gypoCASIQX2r1+yoOkM1OgAtMUgw
Message-ID: 
References: <4D25AD41.7060306@alvestrand.no>
In-Reply-To: <4D25AD41.7060306@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtc-web@alvestrand.no" 
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at	IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 09:36:32 -0000

Harald,

With one exception, this draft charter does not mention signalling (SIP/SDP=
), and I assume it is intended to be out of scope, although that is not exp=
licitly stated.

The one exception is "8) RFC 4574 based Label support for identifying strea=
ms purpose".
This is an SDP attribute. How would this be used if SDP is indeed out of sc=
ope? If SDP is in scope, we certainly need more text describing its relevan=
ce.

John


> -----Original Message-----
> From: rtc-web-bounces@alvestrand.no=20
> [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Harald Alvestrand
> Sent: 06 January 2011 11:54
> To: 'dispatch@ietf.org'
> Cc: rtc-web@alvestrand.no
> Subject: [RTW] Charter proposal: The activity hitherto known=20
> as "RTC-WEB at IETF"
>=20
> This is the first of 3 messages going to the DISPATCH list=20
> (in the hope=20
> of keeping discussions somewhat organized).
>=20
> This is the draft of a charter for an IETF working group to=20
> consider the=20
> subject area of "Real time communication in the Web browser=20
> platform".=20
> This is one of a paired set of activities, the other one being a W3C=20
> activity (either within an existing WG or in a new WG) that=20
> defines APIs=20
> to this functionality.
>=20
> The two other messages will contain the W3C proposed charter and a=20
> kickoff for what's usually the most distracting topic in any such=20
> discussion: The name of the group.
> Without further ado:
>=20
> -------------------------------------
>=20
> Version: 2
>=20
> Possible Names:
> 
>=20
> Body:
>=20
> Many implementations have been made that use a Web browser to support=20
> interactive communications directly between users including voice,=20
> video, collaboration and gaming, but until now, such=20
> applications have=20
> required the installation of nonstandard plugins and browser=20
> extensions.=20
> There is a desire to standardize such functionality, so that=20
> this type=20
> of application can be run in any compatible browser.
>=20
> Traditionally, the W3C has defined API and markup languages=20
> such as HTML=20
> that work in conjunction with with the IETF over the wire=20
> protocols such=20
> as HTTP to allow web browsers to display media that does not=20
> have real=20
> time interactive constraints with another human.
>=20
> The W3C and IETF plan to collaborate together in their=20
> traditional way=20
> to meet the evolving needs of browsers. Specifically the IETF will=20
> provide a set of on the wire protocols, including RTP, to=20
> meet the needs=20
> on interactive communications, and the W3C will define the API and=20
> markup to allow web application developers to control the on the wire=20
> protocols. This will allow application developers  to write=20
> applications=20
> that run in a browser and facilitate interactive=20
> communications between=20
> users for voice and video communications, collaboration, and gaming.
>=20
> This working group will select and define a minimal set of protocols=20
> that will enable browsers to:
>=20
> * have interactive real time voice and video between users using RTP
> * interoperate with compatible voice and video systems that=20
> are not web=20
> based
> * support direct flows of non RTP application data between=20
> browsers for=20
> collaboration and gaming applications
>=20
> Fortunately very little development of new protocol at IETF=20
> is required=20
> for this, only selection of existing protocols and selection=20
> of minimum=20
> capabilities to ensure interoperability. The following protocols are=20
> candidates for including in the profile set:
>=20
> 1) RTP/ RTCP
>=20
> 2) a baseline audio codec for high quality interactive audio. Opus
> will be considered as one of the candidates
>=20
> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
> will be considered
>=20
> 4) a baseline video codec. H.264 and VP8 will be considered
>=20
> 5) Diffserv based QoS
>=20
> 6) NAT traversal using ICE
>=20
> 7) RFC 4833 based DTMF transport
>=20
> 8) RFC 4574 based Label support for identifying streams purpose
>=20
> 9) Secure RTP and keying
>=20
> 10) support for IPv4, IPv6 and dual stack browsers
>=20
> The working group will cooperate closely with the W3C activity that=20
> specifies a semantic level API that allows the control and=20
> manipulation=20
> of all the functionality above. In addition, the API needs to=20
> communicate state information and events about what is=20
> happening in the=20
> browser that to applications running in the browser. These events and=20
> state need to include information such as: receiving RFC 4833=20
> DTMF, RTP=20
> and RTCP statistics, state of DTLS/SRTP,  and signalling state.
>=20
> The following topics will be out of scope for the initial=20
> phase of the=20
> WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST,=20
> Geolocation, IM & Presence, NSIS, Resource Priority,
>=20
> Milestones:
>=20
> February 2011 Candidate "sample" documents circulated to DISPATCH
>=20
> March 2011 BOF at IETF Prague
>=20
> April 2011 WG charter approved by IESG. Chosen document sets=20
> adopted as=20
> WG documents
>=20
> May 2011 Functionality to include and main alternative=20
> protocols identified
>=20
> July 2011 IETF meeting
>=20
> Aug 2011 Draft with text reflecting agreement of what the=20
> protocol set=20
> should be
>=20
> Nov 2010 Documentation specifying mapping of protocol=20
> functionality to=20
> W3C-specified API produced
>=20
> Dec 2011 Protocol set specification to IESG
>=20
> April 2012 API mapping document to IESG
>=20
> _______________________________________________
> RTC-Web mailing list
> RTC-Web@alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
> =

From john.elwell@siemens-enterprise.com  Fri Jan  7 01:54:55 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D43B3A67F6 for ; Fri,  7 Jan 2011 01:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level: 
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FI2g12t5aj9o for ; Fri,  7 Jan 2011 01:54:53 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 15BAD3A6804 for ; Fri,  7 Jan 2011 01:54:52 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2925478; Fri, 7 Jan 2011 10:56:58 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id AE1281EB82AB; Fri,  7 Jan 2011 10:56:58 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 7 Jan 2011 10:56:58 +0100
From: "Elwell, John" 
To: Stephen Botzko , Henry Sinnreich 
Date: Fri, 7 Jan 2011 10:56:56 +0100
Thread-Topic: [dispatch] [RTW] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
Thread-Index: AcuoSHG0monvOmqxQemqgLl1wTi+MgGCFfkA
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Bernard Aboba , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 09:54:55 -0000

I also agree that codecs such as H.264 AVC need to be considered, because o=
f interworking with non-RTC-web users, conference bridges, etc.. An importa=
nt part of the proposed charter is:
"* interoperate with compatible voice and video systems that are not web=20
based"

John
=20

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Stephen Botzko
> Sent: 30 December 2010 17:39
> To: Henry Sinnreich
> Cc: Bernard Aboba; rtc-web@alvestrand.no; dispatch@ietf.org
> Subject: Re: [dispatch] [RTW] Codec standardization (Re: Fwd:=20
> New Version Notification for=20
> draft-alvestrand-dispatch-rtcweb-protocols-00)
>=20
> I'm with Bernard and David on this one. =20
>=20
> This is different from the audio case, as hardware=20
> acceleration is much more important for video, particularly=20
> for mobile.
>=20
> Stephen Botzko
>=20
>=20
> On Thu, Dec 30, 2010 at 12:02 PM, Henry Sinnreich=20
>  wrote:
>=20
>=20
> 	This should mark a good progress for the discussion=20
> ending this year and we
> 	hopefully can all agree:
> =09
>=20
> 	> These concepts of "self interest" not necessarily=20
> align with each other, let
> 	> alone with the
> 	> "self interest" of users, who may primarily care=20
> about how many other users
> 	> they can connect
> 	> with.
> =09
> =09
> 	The interests of users must be first and foremost in=20
> mind for defining a
> 	standard for the default video codec.
> =09
> 	It includes not passing the cost of licensing in=20
> perpetuity along to users.
> =09
> 	Given a choice for open source and/or free video codecs=20
> such as Theora and
> 	VP8, the IETF has several good options to choose from,=20
> also defining of a
> 	video codec from ground up.
> =09
> 	Thanks,
> =09
> 	Henry
> =09
>=20
>=20
> 	On 12/30/10 12:09 AM, "Bernard Aboba"=20
>  wrote:
> =09
> 	> For video codecs, "self interest" may be influenced=20
> by a number of factors.
> 	>
> 	> For example, for a mobile applications developer,=20
> "self interest" may focus
> 	> on
> 	> aspects such as performance, battery life and=20
> maintenance costs.  If a given
> 	> codec is
> 	> supported in the hardware or operating system of=20
> their target platform, then
> 	> the developer
> 	> may perceive it being low "cost" to them.
> 	>
> 	> For a chipset manufacturer, "self interest" may be=20
> determined by the demand
> 	> for chipsets
> 	> incorporating a given codec, as well as the=20
> associated licensing fees.
> 	> Typically the goal
> 	> is to maximize revenue minus cost, not just to=20
> minimize "cost".
> 	>
> 	> These concepts of "self interest" not necessarily=20
> align with each other, let
> 	> alone with the
> 	> "self interest" of users, who may primarily care=20
> about how many other users
> 	> they can connect
> 	> with.
> 	>
> 	> -----Original Message-----
> 	> From: rtc-web-bounces@alvestrand.no=20
> [mailto:rtc-web-bounces@alvestrand.no]
> 	> On Behalf Of David Singer
> 	> Sent: Wednesday, December 29, 2010 8:08 PM
> 	> To: Heinrich Sinnreich
> 	> Cc: rtc-web@alvestrand.no; dispatch@ietf.org
> 	> Subject: Re: [RTW] [dispatch] Codec standardization=20
> (Re: Fwd: New Version
> 	> Notification for=20
> draft-alvestrand-dispatch-rtcweb-protocols-00)
> 	>
> 	> Heinrich,
> 	>
> 	> 'best' is not always IPR-cost-free.  Sometimes it is,=20
> sometimes it isn't.
> 	> You seem unable to see any other possibility than=20
> your own, alas.  I could
> 	> wish for 'fates' for any number of technologies, but=20
> I don't: I choose them
> 	> when they suit, and others when they don't.  I=20
> suggest we do the same.
> 	>
> 	> I have no objection to the development and deployment=20
> of new codecs, with
> 	> varying terms, quality, complexity, and so on. This=20
> is a varied market that
> 	> deserves varied tools.  I do object to making=20
> decisions based on only one
> 	> criterion, however.
> 	>
> 	>
> 	> On Dec 26, 2010, at 18:12 , Heinrich Sinnreich wrote:
> 	>
> 	>>> I think we should consider the balance
> 	>>> between cost, risk, quality, and existing adoption,=20
> and it would be
> 	> foolish to
> 	>>> omit cost-bearing codecs from that analysis, as=20
> H.264 is widely used
> 	> already.
> 	>>
> 	>> I am not sure where this discussion is going, though=20
> it reminds us of the
> 	>> discussions when arguing about SIP vs. H.323 in the IETF.
> 	>> "Everybody" was shipping H.323 in overwhelming=20
> quantity, but somehow the
> 	>> IETF did not buy it.
> 	>>
> 	>> As an hopeless optimist; maybe H.264 will have the=20
> same fate since at
> 	> least
> 	>> it's considerable IP baggage is so well known...
> 	>>
> 	>> It is hard to imagine the IETF and indeed the market=20
> will ignore the
> 	>> creativity of all the codec developers out there and=20
> the evolving
> 	> technology
> 	>> that empowers them. Plain self interest should=20
> motivate embracing new
> 	>> IP-free a/v codecs for the RTC Web. They will arrive=20
> anyway one way or
> 	>> another.
> 	>>
> 	>> [Well deployed technology has a proven way to make=20
> it over the threshold
> 	>> into history :-)]
> 	>>
> 	>
> 	> David Singer
> 	> Multimedia and Software Standards, Apple Inc.
> 	>
> 	> _______________________________________________
> 	> RTC-Web mailing list
> 	> RTC-Web@alvestrand.no
> 	> http://www.alvestrand.no/mailman/listinfo/rtc-web
> 	>
> =09
> =09
> 	_______________________________________________
> 	dispatch mailing list
> 	dispatch@ietf.org
> 	https://www.ietf.org/mailman/listinfo/dispatch
> =09
>=20
>=20
> =

From jose_javier.garcia_aranda@alcatel-lucent.com  Fri Jan  7 04:35:08 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA993A6834 for ; Fri,  7 Jan 2011 04:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.694
X-Spam-Level: 
X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[AWL=0.554,  BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfByo-ctdSRF for ; Fri,  7 Jan 2011 04:35:06 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id AF85C3A682E for ; Fri,  7 Jan 2011 04:35:05 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p07CX3ZO016700 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jan 2011 13:33:03 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 7 Jan 2011 13:33:03 +0100
From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" 
To: "'dispatch@ietf.org'" 
Date: Fri, 7 Jan 2011 13:33:01 +0100
Thread-Topic: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 2
Thread-Index: AcugSvRWsT7gbY+GSyqLnLGU53HqvAAGPezQA4BiV1A=
Message-ID: <3349FECF788C984BB34176D70A51782F18574396@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
References: <3349FECF788C984BB34176D70A51782F18374A47@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4D0F5BD8.4040506@alvestrand.no> 
Accept-Language: en-US
Content-Language: es-ES
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F18574396FRMRSSXCHMBSB3d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83
Cc: "pedrochas@dit.upm.es" , "CUBILLO PASTOR, CLARA \(CLARA\)" , "jquemada@dit.upm.es" , "gabriel@dit.upm.es" , "barcenilla@dit.upm.es" , "jsr@dit.upm.es" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" 
Subject: [dispatch] Charter proposal for Q4S WG ( formerly Q-HTTP) Version 2
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 12:35:08 -0000

--_000_3349FECF788C984BB34176D70A51782F18574396FRMRSSXCHMBSB3d_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

hi folks,

that's the version 2 of Q4S charter , after including the received feedback

The  rtcweb inititative involves to identify and find a consensus on a set =
of components to communicate universally for real-time communications. Insi=
de this approach, Q4S protocol could be part of this set of agreed protocol=
s, and this goal is part of Q4S objectives. This is an additional point to =
focus, not included in the followin charter, however it is in our aim.


thanks ,

- Jose Javier


Description of Working group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

   Problem Statement:

   The QoS over Internet is a hot issue today. Current QoS handling
   mechanisms used in  modern network transport layers (MPLS, RSVP,
   Diffserv,Traffic Engineering) do not provide  themselves a
   QoS-on-demand end-to-end solution and existing adaptative
   solutions based on In-band Control protocols (such as RTCP)
   are very difficult to combine with any other protocols for which
   they have not been designed for.

   Four Network Parameters comprises the QoS at application level:
   Bandwidth, packet-loss, latency and Jitter.

   Interactive-video applications define flows in both directions.
   Different applications require different constraints (in terms of
   latency, jitter, packet loss) in one or both directions and
   different responsiveness. The proposed solution must be an
   effective out-of-band application level protocol capable of
   reacting when any of these constraints are violated. Such protocol
   must trigger adaptive solutions and/or QoS network profile changes.

   A Q4S protocol monitors and sends alerts, which are useful to know when
   those types of solutions should be taken, but it does not assume that
   that the network is not doing deep packet inspection or differential
   treatment of services.

   Currently content providers are only able to provide services based
   on adaptative methods or last-mille deployments which prefer
   dedicated network resources (vs. Internet), and therefore, restricts
   the subscriber population and increases the costs.

   Objetives:

   The goal of this working group is to define a
   QoS application-level  standard protocol optimized for its use over
   the internet that may be widely implemented and easily managed
   by application developers and service providers.

   The core technical considerations for such protocol include, but
   are not necessarily limited to, the following:

   1. Protocol design to be used in interactive applications (including
      virtualized videogames,and interative-video applications)

   2. Ensuring interoperability with all existing transport protocols

   3. Optimize to use low bit rates in the Q4S control flow (typlically
      below 2.4 kbps) in order to produce a minimum disturbance in
      the application flows.

   4. To ensure a feasible practical implementation based on
      policy servers and interoperability between service providers


   Deliverables:

   1. Specification of protocol that meets the requirements in the
      form of an Internet-Draft that defines the negotiation of QoS
      parameters, the measurement process and alert mechanisms.

   2. Dimensioning rules and performance analysis

   3. A set of technical requirements for a practical
      implementation which may include adaptative solutions and/or
      QoS profile modification.


Goals and Milestiones
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 Nov 2010    Submit Internet-Draft as a proposed standard for QoS
             application-level protocol

             Proposed charter for Q4S WG

             Informational document with rules for dimensioning
             and performance analysis

             Specification of architecture document for implementation







--_000_3349FECF788C984BB34176D70A51782F18574396FRMRSSXCHMBSB3d_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







hi folks,


 


that's the version 2 of Q4S charter , after incl=
uding=20
the received feedback


 


The  rtcweb inititative involves to identif=
y and=20
find a consensus on a set of components to communicate universally for real=
-time=20
communications. Inside this approach, Q4S protocol could be part of this se=
t of=20
agreed protocols, and this goal is part of Q4S objectives. This is an addit=
ional=20
point to focus, not included in the followin charter, however it is in our=
=20
aim.


 




 


thanks ,


 


- Jose=20
Javier


 



Description of Working=20
group
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D


 


   Problem Statement:
  =
=20

   The QoS over Internet is a hot issue today. Current QoS=20
handling
   mechanisms used in  modern network transport=
=20
layers (MPLS, RSVP, 
   Diffserv,Traffic Engineering) do not=20
provide  themselves a 
   QoS-on-demand end-to-end soluti=
on=20
and existing adaptative 
   solutions based on In-band Control=
=20
protocols (such as RTCP) 
   are very difficult to combine wit=
h any=20
other protocols for which 
   they have not been designed=20
for.


 


   Four Network Parameters comprises =
the QoS=20
at application level:
   Bandwidth, packet-loss, latency and=20
Jitter.
   
   Interactive-video applications def=
ine=20
flows in both directions. 
   Different applications require=20
different constraints (in terms of 
   latency, jitter, packet=
=20
loss) in one or both directions and 
   different responsivene=
ss.=20
The proposed solution must be an 
   effective out-of-band=20
application level protocol capable of 
   reacting when any of=
=20
these constraints are violated. Such protocol 
   must trigger=
=20
adaptive solutions and/or QoS network profile changes.


 


   A Q4S protocol monitors and sends =
alerts,=20
which are useful to know when 
   those types of solutions sho=
uld=20
be taken, but it does not assume that 
   that the network is =
not=20
doing deep packet inspection or differential 
   treatment of=
=20
services.
   
   Currently content providers are =
only=20
able to provide services based 
   on adaptative methods or=20
last-mille deployments which prefer 
   dedicated network reso=
urces=20
(vs. Internet), and therefore, restricts 
   the subscriber=20
population and increases the costs.
   
  =20
Objetives:


 


   The goal of this working group is =
to define=20
a 
   QoS application-level  standard protocol optimized =
for=20
its use over 
   the internet that may be widely implemented a=
nd=20
easily managed
   by application developers and service=20
providers.
   
   The core technical consideratio=
ns=20
for such protocol include, but 
   are not necessarily limited=
 to,=20
the following:
   
   1. Protocol design to be us=
ed in=20
interactive applications (including
     =20
virtualized videogames,and interative-video applications)
  =20

   2. Ensuring interoperability with all existing transport=20
protocols
   
   3. Optimize to use low bit rates=
 in=20
the Q4S control flow (typlically 
      below 2=
.4=20
kbps) in order to produce a minimum disturbance in=20

      the application flows.
  =20

   4. To ensure a feasible practical implementation based on=
=20

      policy servers and interoperability betw=
een=20
service providers
   
     =20

   Deliverables:
   
   1. Specific=
ation=20
of protocol that meets the requirements in the=20

      form of an Internet-Draft that defines t=
he=20
negotiation of QoS
      parameters, the measur=
ement=20
process and alert mechanisms.
   
   2. Dimension=
ing=20
rules and performance analysis
   
   3. A set of=
=20
technical requirements for a practical
     =20
implementation which may include adaptative solutions=20
and/or
      QoS profile modification.


 



Goals and Milestiones
=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


 


 Nov 2010    Submit Interne=
t-Draft=20
as a proposed standard for QoS=20

            =
;=20
application-level=20
protocol
          &nb=
sp; =20

            =
;=20
Proposed charter for Q4S=20
WG
           &nb=
sp;=20

            =
;=20
Informational document with rules for dimensioning=20

            =
; and=20
performance=20
analysis
          &nb=
sp; =20

            =
;=20
Specification of architecture document for implementation


 


 


 


 


 


 


--_000_3349FECF788C984BB34176D70A51782F18574396FRMRSSXCHMBSB3d_--

From harald@alvestrand.no  Fri Jan  7 05:05:01 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927CC3A68B9 for ; Fri,  7 Jan 2011 05:05:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.88
X-Spam-Level: 
X-Spam-Status: No, score=-102.88 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvMr0ZekIt+l for ; Fri,  7 Jan 2011 05:05:00 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id BB7273A68B8 for ; Fri,  7 Jan 2011 05:05:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2BDC739E2B1; Fri,  7 Jan 2011 14:06:42 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0YH90sxnW-h; Fri,  7 Jan 2011 14:06:40 +0100 (CET)
Received: from [172.16.40.162] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1B7A139E08A; Fri,  7 Jan 2011 14:06:40 +0100 (CET)
Message-ID: <4D270FF6.2000403@alvestrand.no>
Date: Fri, 07 Jan 2011 14:07:02 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: "Elwell, John" 
References: 		 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bernard Aboba , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 13:05:01 -0000

On 01/07/11 10:56, Elwell, John wrote:
> I also agree that codecs such as H.264 AVC need to be considered, because of interworking with non-RTC-web users, conference bridges, etc.. An important part of the proposed charter is:
> "* interoperate with compatible voice and video systems that are not web
> based"
This can turn out to be seriously problematic if we don't constrain it 
carefully - when we wrote this, my thinking was that it meant "if 
devices send and receive media in formats that we support, and the setup 
is performed in a reasonable way through intermediaries, we should be 
able to send media directly to them".

I see the use case that we *have* to support as the browser-to-browser 
use case. If we are able to support other use cases too, that is a good 
thing, but very much a lower priority to me. Opinions may differ.

                 Harald


From harald@alvestrand.no  Fri Jan  7 05:28:37 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EF53A683B for ; Fri,  7 Jan 2011 05:28:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.809
X-Spam-Level: 
X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eiaY1DgR2Qa for ; Fri,  7 Jan 2011 05:28:36 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id AE0D93A68C2 for ; Fri,  7 Jan 2011 05:28:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F30E939E2BB; Fri,  7 Jan 2011 14:30:17 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgtnmsXYtu98; Fri,  7 Jan 2011 14:30:16 +0100 (CET)
Received: from [172.16.40.162] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1681F39E08A; Fri,  7 Jan 2011 14:30:15 +0100 (CET)
Message-ID: <4D27157F.6050701@alvestrand.no>
Date: Fri, 07 Jan 2011 14:30:39 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: Ted Hardie 
References: <4D25AD41.7060306@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 13:28:37 -0000

On 01/06/11 19:43, Ted Hardie wrote:
> Hi Harald,
>
> Thanks for putting this together; some discussion in-line.
>
> On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand  wrote:
>> This is the first of 3 messages going to the DISPATCH list (in the hope of
>> keeping discussions somewhat organized).
>>
>> This is the draft of a charter for an IETF working group to consider the
>> subject area of "Real time communication in the Web browser platform". This
>> is one of a paired set of activities, the other one being a W3C activity
>> (either within an existing WG or in a new WG) that defines APIs to this
>> functionality.
>>
>> The two other messages will contain the W3C proposed charter and a kickoff
>> for what's usually the most distracting topic in any such discussion: The
>> name of the group.
>> Without further ado:
>>
>> -------------------------------------
>>
>> Version: 2
>>
>> Possible Names:
>> 
>>
>> Body:
>>
>> Many implementations have been made that use a Web browser to support
>> interactive communications directly between users including voice, video,
>> collaboration and gaming, but until now, such applications have required the
>> installation of nonstandard plugins and browser extensions. There is a
>> desire to standardize such functionality, so that this type of application
>> can be run in any compatible browser.
>>
> In at least some of the contexts identified above, there is a
> long-lived identifier
> associated with the individuals who will have interactive
> communications; that is,
> there is a context-specific presence architecture in addition to the
> implementation-specific
> real-time communications.  Though the text below occasionally says "users",
> there does not seem to be any work being defined that would touch on this.
> I see that in the last sentence you explicitly rule it out of scope.
> Without this,
> this seems to be limited to an architecture where a mediating server provides
> the initial signaling path.  If that is the scope, I think that should be made
> explicit as a design statement, not inferred from the lack of presence.
I think what you mean is that at this level, we're not taking a position 
on what an "user" is, or whether the concept of "user" even has meaning 
for the application (think chatroulette for one example of an 
application where there are no long-lived user identifiers).

I would certainly agree that this is a reasonable restriction of our 
work, and would welcome suggested text on how to write that into the 
charter.
>> Traditionally, the W3C has defined API and markup languages such as HTML
>> that work in conjunction with with the IETF over the wire protocols such as
>> HTTP to allow web browsers to display media that does not have real time
>> interactive constraints with another human.
>>
>> The W3C and IETF plan to collaborate together in their traditional way to
>> meet the evolving needs of browsers. Specifically the IETF will provide a
>> set of on the wire protocols, including RTP, to meet the needs on
>> interactive communications, and the W3C will define the API and markup to
>> allow web application developers to control the on the wire protocols. This
>> will allow application developers  to write applications that run in a
>> browser and facilitate interactive communications between users for voice
>> and video communications, collaboration, and gaming.
>>
>> This working group will select and define a minimal set of protocols that
>> will enable browsers to:
>>
>> * have interactive real time voice and video between users using RTP
>> * interoperate with compatible voice and video systems that are not web
>> based
>> * support direct flows of non RTP application data between browsers for
>> collaboration and gaming applications
>>
> Okay "direct flows of non-RTP application data" goes beyond scope creep;
> to satisfy this completely, we are talking an end-point-to-end-point tunnel,
> which will run afoul of a lot of folks who dearly love packet inspection.  I
> would say that it would be best to first tackle the voice/video bits and then
> tackle this problem.  Re-charter the WG to cover this, in other words, after
> the first bit is done.
>
> I also note that you're using "between browsers", rather than "among browsers".
> Is it intended that this facility should allow for multi-party communication?
> Leaving aside the non-RTP issues, that would add floor control, media mixing,
> etc. to the task list.  Again, I think it should either be explicitly
> in-scope or out-of-scope.
I did not intend "between" to indicate that there were only two parties, 
but think that we're building point-to-point communications, not N-to-N.

In one interpretation of the distinction .... I think we're 
standardizing point-to-point communications at this time, since all the 
proven-viable multipoint communication applications have been built out 
of point-to-point links rather than using underlying multipoint 
technologies like multicast.

In another interpretation ... I think we should limit ourselves to 
providing a toolbox. I think floor control (except for possibly 
providing the signalling channels floor control needs) is out of scope; 
MAITAI may be a better place to discuss media mixing.

>> Fortunately very little development of new protocol at IETF is required for
>> this, only selection of existing protocols and selection of minimum
>> capabilities to ensure interoperability. The following protocols are
>> candidates for including in the profile set:
>>
>> 1) RTP/ RTCP
>>
>> 2) a baseline audio codec for high quality interactive audio. Opus
>> will be considered as one of the candidates
>>
>> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
>> will be considered
>>
>> 4) a baseline video codec. H.264 and VP8 will be considered
>>
>> 5) Diffserv based QoS
>>
>> 6) NAT traversal using ICE
>>
> The ICE spec is clear that the NAT traversal it provides does not
> help establish the signaling between agents.  For this browser-to-browser
> mechanism, if we are limiting this to situations where a mediating web server
> provides the initial signaling path, that's okay.  If there is a
> different model, though,
> we may need additional tools here.
If we can make the mediating-web-server model work, I think we have 
success; if we can't make it work, we have a failure. So obviously 
that's my first priority. What text changes do you think are needed?
>> 7) RFC 4833 based DTMF transport
>>
>> 8) RFC 4574 based Label support for identifying streams purpose
>>
>> 9) Secure RTP and keying
>>
>> 10) support for IPv4, IPv6 and dual stack browsers
>>
>> The working group will cooperate closely with the W3C activity that
>> specifies a semantic level API that allows the control and manipulation of
>> all the functionality above. In addition, the API needs to communicate state
>> information and events about what is happening in the browser that to
>> applications running in the browser.
> I think the sentence above has some extra words; is the browser talking
> to application running in the browser?  Can it be re-phrased?
I think there's an extra "that" - when an event happens at the 
communications interface, this event needs to be propagated over the API 
to the Javascript that is running in a Web page - that Web page is what 
I've been thinking of as "the application". (There are other moves 
around that want to run "web pages" in other contexts than a currently 
open tab in a broswer, but for the moment, "a tab in a browser", or even 
"a set of tabs in a browser" is a reasonable synonym for "application", 
I think).
> These events and state need to include
>> information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state
>> of DTLS/SRTP,  and signalling state.
>>
>> The following topics will be out of scope for the initial phase of the WG
>> but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocation,
>> IM&  Presence, NSIS, Resource Priority,
>>
>> Milestones:
>>
>> February 2011 Candidate "sample" documents circulated to DISPATCH
>>
>> March 2011 BOF at IETF Prague
>>
>> April 2011 WG charter approved by IESG. Chosen document sets adopted as WG
>> documents
>>
>> May 2011 Functionality to include and main alternative protocols identified
>>
>> July 2011 IETF meeting
>>
>> Aug 2011 Draft with text reflecting agreement of what the protocol set
>> should be
>>
>> Nov 2010 Documentation specifying mapping of protocol functionality to
>> W3C-specified API produced
>>
>> Dec 2011 Protocol set specification to IESG
>>
>> April 2012 API mapping document to IESG
>>
> Pretty aggressive, given the number of moving parts.  It's also not
> clear why the November 2011 doc (I assume 2010 is a typo) is
> done in the IETF, rather than the W3C.  Or is it joint work?
More or less done this way at random. I think of this as joint work; 
documents may move between the organizations as we progress, but I'm not 
sure how the W3C document model works yet.


From john.elwell@siemens-enterprise.com  Fri Jan  7 05:39:34 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883613A68BE for ; Fri,  7 Jan 2011 05:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppkwJUns9U7I for ; Fri,  7 Jan 2011 05:39:33 -0800 (PST)
Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 7263B3A68BC for ; Fri,  7 Jan 2011 05:39:33 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2920520; Fri, 7 Jan 2011 14:41:38 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 0836423F0290; Fri,  7 Jan 2011 14:41:38 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 7 Jan 2011 14:41:37 +0100
From: "Elwell, John" 
To: Harald Alvestrand 
Date: Fri, 7 Jan 2011 14:41:37 +0100
Thread-Topic: [RTW] [dispatch] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
Thread-Index: Acuua8k4TcuRnB6NQjSt9qtkkBFheQAA9EeA
Message-ID: 
References:     <4D270FF6.2000403@alvestrand.no>
In-Reply-To: <4D270FF6.2000403@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Bernard Aboba , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 13:39:34 -0000

=20

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]=20
> Sent: 07 January 2011 13:07
> To: Elwell, John
> Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba;=20
> rtc-web@alvestrand.no; dispatch@ietf.org
> Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd:=20
> New Version Notification for=20
> draft-alvestrand-dispatch-rtcweb-protocols-00)
>=20
> On 01/07/11 10:56, Elwell, John wrote:
> > I also agree that codecs such as H.264 AVC need to be=20
> considered, because of interworking with non-RTC-web users,=20
> conference bridges, etc.. An important part of the proposed=20
> charter is:
> > "* interoperate with compatible voice and video systems=20
> that are not web
> > based"
> This can turn out to be seriously problematic if we don't=20
> constrain it=20
> carefully - when we wrote this, my thinking was that it meant "if=20
> devices send and receive media in formats that we support,=20
> and the setup=20
> is performed in a reasonable way through intermediaries, we should be=20
> able to send media directly to them".
>=20
> I see the use case that we *have* to support as the=20
> browser-to-browser=20
> use case. If we are able to support other use cases too, that=20
> is a good=20
> thing, but very much a lower priority to me. Opinions may differ.
[JRE] I disagree. I believe the ability to work with non-RTP-web users is e=
qually important. Take enterprises for example - they don't want a flag day=
 when every user changes to RTP-web at the same time - they need to migrate=
 users at a convenient pace.

One of the benefits of reusing existing protocols such as RTP is that inter=
working with non-RTP-web users and other equipment (such as MCUs) should be=
 feasible. But this also means using appropriate codecs, to avoid having to=
 insert transcoders.

John

>=20
>                  Harald
>=20
> =

From harald@alvestrand.no  Fri Jan  7 06:23:19 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05B03A68D7 for ; Fri,  7 Jan 2011 06:23:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.767
X-Spam-Level: 
X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhHYQdqQSfrS for ; Fri,  7 Jan 2011 06:23:18 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id AF7C33A68D4 for ; Fri,  7 Jan 2011 06:23:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9B9A39E2BB; Fri,  7 Jan 2011 15:25:00 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NorUx0Fb7751; Fri,  7 Jan 2011 15:25:00 +0100 (CET)
Received: from [172.16.40.162] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 77AFF39E08A; Fri,  7 Jan 2011 15:24:59 +0100 (CET)
Message-ID: <4D272251.5090505@alvestrand.no>
Date: Fri, 07 Jan 2011 15:25:21 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: "Elwell, John" 
References: 		  <4D270FF6.2000403@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bernard Aboba , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 14:23:19 -0000

On 01/07/11 14:41, Elwell, John wrote:
>
>
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>> Sent: 07 January 2011 13:07
>> To: Elwell, John
>> Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba;
>> rtc-web@alvestrand.no; dispatch@ietf.org
>> Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd:
>> New Version Notification for
>> draft-alvestrand-dispatch-rtcweb-protocols-00)
>>
>> On 01/07/11 10:56, Elwell, John wrote:
>>> I also agree that codecs such as H.264 AVC need to be
>> considered, because of interworking with non-RTC-web users,
>> conference bridges, etc.. An important part of the proposed
>> charter is:
>>> "* interoperate with compatible voice and video systems
>> that are not web
>>> based"
>> This can turn out to be seriously problematic if we don't
>> constrain it
>> carefully - when we wrote this, my thinking was that it meant "if
>> devices send and receive media in formats that we support,
>> and the setup
>> is performed in a reasonable way through intermediaries, we should be
>> able to send media directly to them".
>>
>> I see the use case that we *have* to support as the
>> browser-to-browser
>> use case. If we are able to support other use cases too, that
>> is a good
>> thing, but very much a lower priority to me. Opinions may differ.
> [JRE] I disagree. I believe the ability to work with non-RTP-web users is equally important. Take enterprises for example - they don't want a flag day when every user changes to RTP-web at the same time - they need to migrate users at a convenient pace.
We have the same situation today when people migrate off PABXes onto 
either VOIP-phones or onto mobile phones; the answer in those cases 
seems to be gateways. Why wouldn't that work in this case?
> One of the benefits of reusing existing protocols such as RTP is that interworking with non-RTP-web users and other equipment (such as MCUs) should be feasible. But this also means using appropriate codecs, to avoid having to insert transcoders.
Can you be more specific about what devices you're thinking of, and how 
many of them there are?
In particular, which devices do you expect to see that don't support 
RTCWeb, but do support STUN?

                        Harald

From john.elwell@siemens-enterprise.com  Fri Jan  7 09:37:27 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53B33A6920 for ; Fri,  7 Jan 2011 09:37:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.521
X-Spam-Level: 
X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iudFHCqOZk2T for ; Fri,  7 Jan 2011 09:37:26 -0800 (PST)
Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 76CCF3A691D for ; Fri,  7 Jan 2011 09:37:26 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2923842; Fri, 7 Jan 2011 18:38:50 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 17E9C23F028E; Fri,  7 Jan 2011 18:38:50 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 7 Jan 2011 18:38:50 +0100
From: "Elwell, John" 
To: Harald Alvestrand 
Date: Fri, 7 Jan 2011 18:38:47 +0100
Thread-Topic: [RTW] [dispatch] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
Thread-Index: AcuudroqLdILRZ7WQ/iS4hJPfaMUfQAGk+RA
Message-ID: 
References:     <4D270FF6.2000403@alvestrand.no>  <4D272251.5090505@alvestrand.no>
In-Reply-To: <4D272251.5090505@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Bernard Aboba , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 17:37:27 -0000

=20

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]=20
> Sent: 07 January 2011 14:25
> To: Elwell, John
> Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba;=20
> rtc-web@alvestrand.no; dispatch@ietf.org
> Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd:=20
> New Version Notification for=20
> draft-alvestrand-dispatch-rtcweb-protocols-00)
>=20
> On 01/07/11 14:41, Elwell, John wrote:
> >
> >
> >> -----Original Message-----
> >> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> >> Sent: 07 January 2011 13:07
> >> To: Elwell, John
> >> Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba;
> >> rtc-web@alvestrand.no; dispatch@ietf.org
> >> Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd:
> >> New Version Notification for
> >> draft-alvestrand-dispatch-rtcweb-protocols-00)
> >>
> >> On 01/07/11 10:56, Elwell, John wrote:
> >>> I also agree that codecs such as H.264 AVC need to be
> >> considered, because of interworking with non-RTC-web users,
> >> conference bridges, etc.. An important part of the proposed
> >> charter is:
> >>> "* interoperate with compatible voice and video systems
> >> that are not web
> >>> based"
> >> This can turn out to be seriously problematic if we don't
> >> constrain it
> >> carefully - when we wrote this, my thinking was that it meant "if
> >> devices send and receive media in formats that we support,
> >> and the setup
> >> is performed in a reasonable way through intermediaries,=20
> we should be
> >> able to send media directly to them".
> >>
> >> I see the use case that we *have* to support as the
> >> browser-to-browser
> >> use case. If we are able to support other use cases too, that
> >> is a good
> >> thing, but very much a lower priority to me. Opinions may differ.
> > [JRE] I disagree. I believe the ability to work with=20
> non-RTP-web users is equally important. Take enterprises for=20
> example - they don't want a flag day when every user changes=20
> to RTP-web at the same time - they need to migrate users at a=20
> convenient pace.
> We have the same situation today when people migrate off PABXes onto=20
> either VOIP-phones or onto mobile phones; the answer in those cases=20
> seems to be gateways. Why wouldn't that work in this case?
> > One of the benefits of reusing existing protocols such as=20
> RTP is that interworking with non-RTP-web users and other=20
> equipment (such as MCUs) should be feasible. But this also=20
> means using appropriate codecs, to avoid having to insert transcoders.
> Can you be more specific about what devices you're thinking=20
> of, and how=20
> many of them there are?
> In particular, which devices do you expect to see that don't support=20
> RTCWeb, but do support STUN?
[JRE] It is true that a lot of existing devices do not support STUN, and re=
ly on intermediaries (SBC) to achieve NAT traversal. However, those interme=
diaries could be made to mediate between RTC-Web devices and other devices.=
 Getting those intermediaries to handle STUN on the RTC-Web side is feasibl=
e - getting them to do transcoding, particularly for video, is an entirely =
different matter. So in other words, it depends how much functionality we a=
re prepared to put into the gateway.

John



>=20
>                         Harald
> =

From henry.sinnreich@gmail.com  Fri Jan  7 10:00:24 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88AB03A68D5 for ; Fri,  7 Jan 2011 10:00:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.131
X-Spam-Level: 
X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[AWL=0.468,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHgzrXxgIzsr for ; Fri,  7 Jan 2011 10:00:23 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 440643A67A1 for ; Fri,  7 Jan 2011 10:00:23 -0800 (PST)
Received: by gwj17 with SMTP id 17so9418570gwj.31 for ; Fri, 07 Jan 2011 10:02:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=mWaqLNUpafLJksvSuGd1FJC3x5s+UQ0o1vmdGFSwoJ4=; b=BTwq+hv4MfGDN1bqMNXqr/n7sOFyRfldlIFGBMG8MTj5UXgj1YaIxg2xZ67kFBExw5 TzIJ9rRpSmweZ384PCMckrzHicTgY5GYLWiQe4QB+Uquya36DWqeCA+Guy4mt2U6iE+J v5OBDs2AbC6kdUxfosdjyqtxKEBz06Uwn/oxg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=rRKZDM6jzIrgDfMiWo+5EOE3aiox0/Kdy2Mb3lfh0Fgw4qXCg+Vporo1me7ENXd3rq baSLHofdvWdS5E4JPuQ6+0nAesJNOFV2b11ytnTGbqKUu5Hnai0B5CZBH2d3Ys+r0Yw6 MkjaTHZA8dNoR2zlN2/LHmXPKpCE+5jqivo4g=
Received: by 10.90.29.13 with SMTP id c13mr3605749agc.95.1294423349422; Fri, 07 Jan 2011 10:02:29 -0800 (PST)
Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id x31sm33821132ana.29.2011.01.07.10.02.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 10:02:26 -0800 (PST)
User-Agent: Microsoft-Entourage/12.28.0.101117
Date: Fri, 07 Jan 2011 12:02:24 -0600
From: Henry Sinnreich 
To: "Elwell, John" , Harald Alvestrand 
Message-ID: 
Thread-Topic: Gateways and does anyone think "H.264 for ever"?
Thread-Index: AcuudroqLdILRZ7WQ/iS4hJPfaMUfQAGk+RAAAD/5pU=
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Bernard Aboba , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: [dispatch] Gateways and does anyone think "H.264 for ever"?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 18:00:24 -0000

Though gateways are a key component in the web architecture and critical
indeed for connectivity with other networks, I believe the scope as outlined
here by Harald is the correct first step.

As for interoperability at the video codec level, several items have to be
balanced

1. The benefits for users (includes cost and performance) first and foremost
2. Give a chance to new and free codec technologies such as VP8 or Theora
3. Interoperability with existing H.264 based systems

Or does anyone think "H.264 for ever"?

Thanks, Henry


On 1/7/11 11:38 AM, "Elwell, John" 
wrote:

>  
> 
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>> Sent: 07 January 2011 14:25
>> To: Elwell, John
>> Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba;
>> rtc-web@alvestrand.no; dispatch@ietf.org
>> Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd:
>> New Version Notification for
>> draft-alvestrand-dispatch-rtcweb-protocols-00)
>> 
>> On 01/07/11 14:41, Elwell, John wrote:
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>>>> Sent: 07 January 2011 13:07
>>>> To: Elwell, John
>>>> Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba;
>>>> rtc-web@alvestrand.no; dispatch@ietf.org
>>>> Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd:
>>>> New Version Notification for
>>>> draft-alvestrand-dispatch-rtcweb-protocols-00)
>>>> 
>>>> On 01/07/11 10:56, Elwell, John wrote:
>>>>> I also agree that codecs such as H.264 AVC need to be
>>>> considered, because of interworking with non-RTC-web users,
>>>> conference bridges, etc.. An important part of the proposed
>>>> charter is:
>>>>> "* interoperate with compatible voice and video systems
>>>> that are not web
>>>>> based"
>>>> This can turn out to be seriously problematic if we don't
>>>> constrain it
>>>> carefully - when we wrote this, my thinking was that it meant "if
>>>> devices send and receive media in formats that we support,
>>>> and the setup
>>>> is performed in a reasonable way through intermediaries,
>> we should be
>>>> able to send media directly to them".
>>>> 
>>>> I see the use case that we *have* to support as the
>>>> browser-to-browser
>>>> use case. If we are able to support other use cases too, that
>>>> is a good
>>>> thing, but very much a lower priority to me. Opinions may differ.
>>> [JRE] I disagree. I believe the ability to work with
>> non-RTP-web users is equally important. Take enterprises for
>> example - they don't want a flag day when every user changes
>> to RTP-web at the same time - they need to migrate users at a
>> convenient pace.
>> We have the same situation today when people migrate off PABXes onto
>> either VOIP-phones or onto mobile phones; the answer in those cases
>> seems to be gateways. Why wouldn't that work in this case?
>>> One of the benefits of reusing existing protocols such as
>> RTP is that interworking with non-RTP-web users and other
>> equipment (such as MCUs) should be feasible. But this also
>> means using appropriate codecs, to avoid having to insert transcoders.
>> Can you be more specific about what devices you're thinking
>> of, and how 
>> many of them there are?
>> In particular, which devices do you expect to see that don't support
>> RTCWeb, but do support STUN?
> [JRE] It is true that a lot of existing devices do not support STUN, and rely
> on intermediaries (SBC) to achieve NAT traversal. However, those
> intermediaries could be made to mediate between RTC-Web devices and other
> devices. Getting those intermediaries to handle STUN on the RTC-Web side is
> feasible - getting them to do transcoding, particularly for video, is an
> entirely different matter. So in other words, it depends how much
> functionality we are prepared to put into the gateway.
> 
> John
> 
> 
> 
>> 
>>                         Harald
>> 



From singer@apple.com  Fri Jan  7 10:21:30 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601083A691C for ; Fri,  7 Jan 2011 10:21:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.413
X-Spam-Level: 
X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVSIjLKKsqXq for ; Fri,  7 Jan 2011 10:21:29 -0800 (PST)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 03B773A68EF for ; Fri,  7 Jan 2011 10:21:29 -0800 (PST)
Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 0A5ACC56375D; Fri,  7 Jan 2011 10:23:36 -0800 (PST)
X-AuditID: 11807136-b7bf8ae00000244a-79-4d275a276cda
Received: from singda.apple.com (singda.apple.com [17.197.20.4]) by relay15.apple.com (Apple SCV relay) with SMTP id AB.04.09290.72A572D4; Fri,  7 Jan 2011 10:23:35 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: David Singer 
In-Reply-To: 
Date: Fri, 7 Jan 2011 10:23:35 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <3620438B-EA9D-4459-AAC4-1E02C2ACA45F@apple.com>
References: 
To: Henry Sinnreich 
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
Cc: Bernard Aboba , "rtc-web@alvestrand.no" , "dispatch@ietf.org" , Harald Alvestrand 
Subject: Re: [dispatch] Gateways and does anyone think "H.264 for ever"?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 18:21:30 -0000

On Jan 7, 2011, at 10:02 , Henry Sinnreich wrote:

> Though gateways are a key component in the web architecture and =
critical
> indeed for connectivity with other networks, I believe the scope as =
outlined
> here by Harald is the correct first step.
>=20
> As for interoperability at the video codec level, several items have =
to be
> balanced
>=20
> 1. The benefits for users (includes cost and performance) first and =
foremost
> 2. Give a chance to new and free codec technologies such as VP8 or =
Theora
> 3. Interoperability with existing H.264 based systems
>=20
> Or does anyone think "H.264 for ever"?

No, MPEG and ITU are always working on the next generation :-).

Your list is a start, but it also needs to consider the availability of =
acceleration and hardware support (maybe that's part of your first =
bullet), and (alas) IPR risk.

David Singer
Multimedia and Software Standards, Apple Inc.


From adam@nostrum.com  Fri Jan  7 11:31:08 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1123A6935 for ; Fri,  7 Jan 2011 11:31:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.847
X-Spam-Level: 
X-Spam-Status: No, score=-101.847 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, PLING_QUERY=1.39, SPF_PASS=-0.001,  USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dnb2YAiLVCtJ for ; Fri,  7 Jan 2011 11:31:07 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 059EA3A6825 for ; Fri,  7 Jan 2011 11:31:06 -0800 (PST)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p07JX2YL089015 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 7 Jan 2011 13:33:02 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4D276A6E.9050607@nostrum.com>
Date: Fri, 07 Jan 2011 13:33:02 -0600
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: David Singer 
References:  <3620438B-EA9D-4459-AAC4-1E02C2ACA45F@apple.com>
In-Reply-To: <3620438B-EA9D-4459-AAC4-1E02C2ACA45F@apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: Bernard Aboba , Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: [dispatch] Known encumberances != exhaustive list of encumberances (was Gateways and does anyone think "H.264 for ever"?)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 19:31:08 -0000

On 1/7/11 12:23 PM, David Singer wrote:
> Your list is a start, but it also needs to consider the availability 
> of acceleration and hardware support (maybe that's part of your first 
> bullet), and (alas) IPR risk.

You've brought up IPR risk a couple of times now, with the implication 
that a codec with known IPR entanglements is somehow safer than a codec 
without. This is a fallacy that we need to dispense with.

The argument with purportedly "IPR Free" technologies is that as-yet 
unidentified patents may apply, and be asserted at a later date. This is 
true.

However, the identification of one or more patents that *do* apply to a 
technology does nothing to mitigate the risk that additional as-yet 
unidentified patents may also apply to it. If you have a set of unknown 
size, finding some elements in the set does nothing to prove that all 
the elements have been found. All you know is that the set is not empty 
(which, in this case, is a drawback).

This shouldn't be news to anyone with even a passing familiarity with 
the situation. As I'm certain you are aware, the MPEG-LA licensing pool 
agreement for H.264 explicitly calls out these potentially unknown 
patents as a risk, and warns licensees that dealing with any resultant 
problems is the licensees' problem, not MPEG-LAs.

In other words: it is every bit as likely that an entity will assert a 
previously unidentified, valid patent against H.264 as it is that a 
company will assert such a patent against Theora or VP8. Implications to 
the contrary are propaganda.

/a

From singer@apple.com  Fri Jan  7 11:51:41 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE9B3A6958 for ; Fri,  7 Jan 2011 11:51:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.742
X-Spam-Level: 
X-Spam-Status: No, score=-105.742 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBeFj0uvpESg for ; Fri,  7 Jan 2011 11:51:39 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 8ED0A3A695A for ; Fri,  7 Jan 2011 11:51:33 -0800 (PST)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 85A8FCA044F5; Fri,  7 Jan 2011 11:53:39 -0800 (PST)
X-AuditID: 11807137-b7bfaae000004d31-4c-4d276f4303c9
Received: from singda.apple.com (singda.apple.com [17.197.20.4]) by relay16.apple.com (Apple SCV relay) with SMTP id C3.0F.19761.34F672D4; Fri,  7 Jan 2011 11:53:39 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: David Singer 
In-Reply-To: <4D276A6E.9050607@nostrum.com>
Date: Fri, 7 Jan 2011 11:53:38 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <48EA89ED-8044-4537-B79D-44CBEE4532DB@apple.com>
References:  <3620438B-EA9D-4459-AAC4-1E02C2ACA45F@apple.com> <4D276A6E.9050607@nostrum.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
Cc: Bernard Aboba , Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] Known encumberances != exhaustive list of encumberances (was Gateways and does anyone think "H.264 for ever"?)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 19:51:41 -0000

On Jan 7, 2011, at 11:33 , Adam Roach wrote:

> On 1/7/11 12:23 PM, David Singer wrote:
>> Your list is a start, but it also needs to consider the availability =
of acceleration and hardware support (maybe that's part of your first =
bullet), and (alas) IPR risk.
>=20
> You've brought up IPR risk a couple of times now, with the implication =
that a codec with known IPR entanglements is somehow safer than a codec =
without. This is a fallacy that we need to dispense with.

No, it's not quite that.  It's that a codec that has been through formal =
standardization (and hence visibility and obligations), has had a formal =
industry-wide call for patents, has a license or licenses, and is widely =
deployed, has a lower (agreed, non-zero) IPR risk than a codec that has =
not.  Those steps have done a lot to flush out patent claims into the =
open.

For example, participants to standards bodies that fail to disclose =
patents face risks if they later try to enforce those patents (recent =
court cases).  So, for at least that set of companies (who form a =
reasonable proportion of the corpus of patent-holding companies in the =
field), we have lowered the risk by placing them under a disclosure =
obligation, and by having formal calls for IPR issued (both by the =
standards body and by those proposing pools).

> This shouldn't be news to anyone with even a passing familiarity with =
the situation. As I'm certain you are aware, the MPEG-LA licensing pool =
agreement for H.264 explicitly calls out these potentially unknown =
patents as a risk, and warns licensees that dealing with any resultant =
problems is the licensees' problem, not MPEG-LAs.

Yes, this is true, because MPEG-LA is run by lawyers and lawyers always =
tell you that they aren't perfect (did we know that already?).

> In other words: it is every bit as likely that an entity will assert a =
previously unidentified, valid patent against H.264 as it is that a =
company will assert such a patent against Theora or VP8. Implications to =
the contrary are propaganda.


No, I'm sorry, the risk levels are substantially different, and any =
implications to the contrary is...well, propaganda.

Take a hypothetical case: Imagine someone were to define a subset of =
MPEG-1 or MPEG-2 video for which it believes all the relevant patents =
have either expired or are RF-licensable.  How much of a risk is there =
that some previously unknown patent would come up and snooker the =
situation?  Why would someone sit in their patent through decades of =
potentially lucrative licensing, and only pop onto the radar when =
something free is defined?  By leveraging the standards process, the =
pool process, and the wide temptation to collect money over decades, we =
could substantially lower the risk of a submarine.  (I can't say it's =
zero, as submarine captains operate to a different definition of =
'rational' from me, it seems!)

Contrast that with someone who believes that they might have a patent on =
Theora.  While it's an open-source codec in development with limited =
deployment, where is the incentive (let alone requirement) to check? A =
statement that Theora needs a license would be unpopular (!), would take =
real time and effort to check (the analysis), and result in bad PR and =
no revenue, even if you win.  On the other hand, if you wait, and then =
someone who is both (a) rich and (b) you don't like or wish to fight =
back against, deploys it, you now have the incentive to check and go =
after it.  There are incentives to wait and see here, alas.

I believe that RF standards have their place, and I work hard to make =
them happen (e.g. I am Apple's AC Rep to the W3C and fully support their =
patent policy).  But we have to be realistic about what we pursue.

RF technologies will surely have a place in this project (many of the =
protocols seem to be in that category), and a complete RF 'profile' may =
well be achievable and meet some needs (for example, if you want to give =
away implementations and make your money some other way, you can't =
afford to pay per-copy on every give-away).  I just remain opposed to =
entering the project with the blinkers on that *only* RF technologies =
will be considered, because I think royalty-bearing ones may well have a =
place, and we should discuss the needs and trade-offs.


David Singer
Multimedia and Software Standards, Apple Inc.


From keith.drage@alcatel-lucent.com  Fri Jan  7 15:01:32 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313B128C121 for ; Fri,  7 Jan 2011 15:01:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.943
X-Spam-Level: 
X-Spam-Status: No, score=-104.943 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HELO_EQ_FR=0.35, PLING_QUERY=1.39,  RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0r+xz+c4Ism for ; Fri,  7 Jan 2011 15:01:31 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 22C7128C11C for ; Fri,  7 Jan 2011 15:01:24 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p07N3K4s031135 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 8 Jan 2011 00:03:21 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 8 Jan 2011 00:03:20 +0100
From: "DRAGE, Keith (Keith)" 
To: Adam Roach , David Singer 
Date: Sat, 8 Jan 2011 00:03:19 +0100
Thread-Topic: [dispatch] Known encumberances != exhaustive list of encumberances (was Gateways and does anyone think "H.264 for ever"?)
Thread-Index: Acuuob5uOyjVY7LoQV2RbIp9KKwDOAAGyeVA
Message-ID: 
References:  <3620438B-EA9D-4459-AAC4-1E02C2ACA45F@apple.com> <4D276A6E.9050607@nostrum.com>
In-Reply-To: <4D276A6E.9050607@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Cc: Bernard Aboba , Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] Known encumberances != exhaustive list of encumberances (was Gateways and does anyone think "H.264 for ever"?)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 23:01:32 -0000

Whether such work is supposedly IPR free or not does not guarantee against =
future IPR claims. I'm not even convinced that claims by an author that som=
ething is IPR free gives any better guarantee of such.

The only hope you have is that a particular solution has been worked on in =
an organisation which requires declaration of IPR from participants, and th=
at all the player in the field with enough money to initiate an IPR claim w=
ere involved in that work.

So if I wanted the safest solution against future IPR claims, I'd go for th=
e one that was worked on by the largest number of significant companies in =
an SDO with an appropriate IPR policy.

Note that this is safest, not safe.


Keith

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach
> Sent: Friday, January 07, 2011 7:33 PM
> To: David Singer
> Cc: Bernard Aboba; Harald Alvestrand; rtc-web@alvestrand.no;=20
> dispatch@ietf.org
> Subject: [dispatch] Known encumberances !=3D exhaustive list of=20
> encumberances (was Gateways and does anyone think "H.264 for ever"?)
>=20
> On 1/7/11 12:23 PM, David Singer wrote:
> > Your list is a start, but it also needs to consider the=20
> availability=20
> > of acceleration and hardware support (maybe that's part of=20
> your first=20
> > bullet), and (alas) IPR risk.
>=20
> You've brought up IPR risk a couple of times now, with the=20
> implication that a codec with known IPR entanglements is=20
> somehow safer than a codec without. This is a fallacy that we=20
> need to dispense with.
>=20
> The argument with purportedly "IPR Free" technologies is that=20
> as-yet unidentified patents may apply, and be asserted at a=20
> later date. This is true.
>=20
> However, the identification of one or more patents that *do*=20
> apply to a technology does nothing to mitigate the risk that=20
> additional as-yet unidentified patents may also apply to it.=20
> If you have a set of unknown size, finding some elements in=20
> the set does nothing to prove that all the elements have been=20
> found. All you know is that the set is not empty (which, in=20
> this case, is a drawback).
>=20
> This shouldn't be news to anyone with even a passing=20
> familiarity with the situation. As I'm certain you are aware,=20
> the MPEG-LA licensing pool agreement for H.264 explicitly=20
> calls out these potentially unknown patents as a risk, and=20
> warns licensees that dealing with any resultant problems is=20
> the licensees' problem, not MPEG-LAs.
>=20
> In other words: it is every bit as likely that an entity will=20
> assert a previously unidentified, valid patent against H.264=20
> as it is that a company will assert such a patent against=20
> Theora or VP8. Implications to the contrary are propaganda.
>=20
> /a
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> =

From adam@nostrum.com  Fri Jan  7 15:40:03 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C405F28C129 for ; Fri,  7 Jan 2011 15:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.802
X-Spam-Level: 
X-Spam-Status: No, score=-101.802 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, PLING_QUERY=1.39, SPF_PASS=-0.001,  USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqLWIs9KBvCw for ; Fri,  7 Jan 2011 15:40:02 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B2E5528C126 for ; Fri,  7 Jan 2011 15:40:01 -0800 (PST)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p07Ng1M0012731 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 7 Jan 2011 17:42:01 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4D27A4C9.1020107@nostrum.com>
Date: Fri, 07 Jan 2011 17:42:01 -0600
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: David Singer 
References:  <3620438B-EA9D-4459-AAC4-1E02C2ACA45F@apple.com> <4D276A6E.9050607@nostrum.com> <48EA89ED-8044-4537-B79D-44CBEE4532DB@apple.com>
In-Reply-To: <48EA89ED-8044-4537-B79D-44CBEE4532DB@apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: Bernard Aboba , Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] Known encumberances != exhaustive list of encumberances (was Gateways and does anyone think "H.264 for ever"?)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Jan 2011 23:40:03 -0000

On 1/7/11 1:53 PM, David Singer wrote:
> On Jan 7, 2011, at 11:33 , Adam Roach wrote:
>> On 1/7/11 12:23 PM, David Singer wrote:
>>> Your list is a start, but it also needs to consider the availability of acceleration and hardware support (maybe that's part of your first bullet), and (alas) IPR risk.
>> You've brought up IPR risk a couple of times now, with the implication that a codec with known IPR entanglements is somehow safer than a codec without. This is a fallacy that we need to dispense with.
> No, it's not quite that.  It's that a codec that has been through formal standardization (and hence visibility and obligations), has had a formal industry-wide call for patents, has a license or licenses, and is widely deployed, has a lower (agreed, non-zero) IPR risk than a codec that has not.  Those steps have done a lot to flush out patent claims into the open.

I don't agree with the assessment of "lower IPR risk" (because of 
mitigating factors I discuss below), but the rest of your assertions are 
true of any technology, not just codecs. And yet we still favor 
unencumbered technologies.

Why? Well, in part because we need to balance these factors against the 
risk that holders of known patents may behave poorly; cf. 
http://www.intomobile.com/2010/11/10/motorola-microsoft-su/

This demonstrates how known encumberances are predictable places that 
things can and do go wrong. If you're worried about tigers, It seems far 
more sensible to pitch your tent where people have been actively looking 
for (and not finding) tigers for over a decade than it is to pitch it in 
a tiger-laden jungle where some of the tigers happen to be on leashes. A 
blind hope that the leashes are strong and short enough is a bit naïve, 
especially when tiger maulings are regularly reported in the news 
(Microsoft v. Motorola, above; Lucent v. Gateway; Multimedia Patent 
Trust v. Microsoft; etc.)


> Take a hypothetical case: Imagine someone were to define a subset of 
> MPEG-1 or MPEG-2 video for which it believes all the relevant patents 
> have either expired or are RF-licensable. How much of a risk is there 
> that some previously unknown patent would come up and snooker the 
> situation? Why would someone sit in their patent through decades of 
> potentially lucrative licensing, and only pop onto the radar when 
> something free is defined?

Like Unisys and the GIF format? Or the Network-1 PoE lawsuits? Or 
Net2Phone sitting on their VoIP patents until 2006, despite competing 
commercially profitable services as early as 2000? I don't know. 
Motivation for this kind of behavior eludes me. But regardless of 
whether we understand the motivation, the behavior doesn't go away.

> Contrast that with someone who believes that they might have a patent on Theora.  While it's an open-source codec in development with limited deployment, where is the incentive (let alone requirement) to check? A statement that Theora needs a license would be unpopular (!), would take real time and effort to check (the analysis), and result in bad PR and no revenue, even if you win.  On the other hand, if you wait, and then someone who is both (a) rich and (b) you don't like or wish to fight back against, deploys it, you now have the incentive to check and go after it.

Google, which has embedded both Theora and VP8 in Chrome, has a $198B 
market cap and $23B of annual revenue.  How large is a company before 
you consider it to have deep enough pockets to bother raiding? I mean, 
if we're talking about software companies, there are only three or so 
that can be legitimately considered "larger" by any financial metric.

> I believe that RF standards have their place, and I work hard to make them happen (e.g. I am Apple's AC Rep to the W3C and fully support their patent policy).

I know, and I've read several of your posts on the topic of HTML5 and 
video codecs. You were a neutral voice of reason in those discussions. 
So perhaps you can understand that I'm a bit confused by your seemingly 
partisan intimation about IPR risk (quoted above), and your propagation 
of the MPEG-LA's unsubstantiated allegations of VP8 patent infringement 
(in your email on December 21st). I prefer the "neutral voice of reason" 
Dave Singer.

>    But we have to be realistic about what we pursue.

How is considering VP8 and/or Theora as a baseline unrealistic? I'm not 
saying either should be a foregone conclusion; I'd like to see a 
well-reasoned discussion around codec selection. But I don't think 
characterizing RF technologies as inherently having excessive IPR risk 
falls into the category of "well-reasoned," even if certain licensing 
entities have engaged in self-serving saber rattling on the topic.


> I just remain opposed to entering the project with the blinkers on that *only* RF technologies will be considered, because I think royalty-bearing ones may well have a place, and we should discuss the needs and trade-offs.

I'm not proposing a change to standard operating procedure within the 
IETF (RFC3979):

    In general, IETF working groups prefer technologies with no known IPR
    claims or, for technologies with claims against them, an offer of
    royalty-free licensing.  But IETF working groups have the discretion
    to adopt technology with a commitment of fair and non-discriminatory
    terms, or even with no licensing commitment, if they feel that this
    technology is superior enough to alternatives with fewer IPR claims
    or free licensing to outweigh the potential cost of the licenses.


But your implication that we should penalize a technology *because* it 
is not known to be encumbered is exactly the opposite of this. If you'd 
like to reverse the IETF's position, I suggest you take the discussion 
to a broader forum, like ietf@ietf.org. I suspect support for your 
proposal will be limited.

To be crystal clear: I'm not proposing excluding royalty-bearing codecs 
from consideration. We need to evaluate each codec on its inherent 
benefits and drawbacks. What I'm objecting to is throwing unrelated 
ballast onto the scale when we're trying to make a reasonable comparison.

/a

From harald@alvestrand.no  Sat Jan  8 06:00:39 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0563C28C0F0 for ; Sat,  8 Jan 2011 06:00:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level: 
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQhLK3n-G4C1 for ; Sat,  8 Jan 2011 06:00:38 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 1B16628C0EA for ; Sat,  8 Jan 2011 06:00:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E367F39E1A3; Sat,  8 Jan 2011 15:02:20 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5bQaTznBW-K; Sat,  8 Jan 2011 15:02:20 +0100 (CET)
Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 15BAF39E11A; Sat,  8 Jan 2011 15:02:19 +0100 (CET)
Message-ID: <4D286E83.9040604@alvestrand.no>
Date: Sat, 08 Jan 2011 15:02:43 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: "Elwell, John" 
References: <4D25AD41.7060306@alvestrand.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" 
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at	IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 08 Jan 2011 14:00:39 -0000

On 01/07/11 10:38, Elwell, John wrote:
> Harald,
>
> With one exception, this draft charter does not mention signalling (SIP/SDP), and I assume it is intended to be out of scope, although that is not explicitly stated.
>
> The one exception is "8) RFC 4574 based Label support for identifying streams purpose".
> This is an SDP attribute. How would this be used if SDP is indeed out of scope? If SDP is in scope, we certainly need more text describing its relevance.
There isn't much text in 4574 - the main point of the RFC seems to be 
that it's possible to create labels for streams before creating the 
stream. Those labels could be independent of the signalling mechanism.

The trend I see now is that most APIs and protocols people define (for 
instance Jabber/XMPP, JSON-based descriptions) have some kind of mapping 
to SDP, so SDP-as-a-format may not be so important (I heartily dislike 
multiple things about the specific format), but SDP-as-a-semantic 
becomes more important over time, and can't be ignored.

                       Harald


From john.elwell@siemens-enterprise.com  Sun Jan  9 23:18:31 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915F13A693A for ; Sun,  9 Jan 2011 23:18:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.522
X-Spam-Level: 
X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPyNXVEYLXhQ for ; Sun,  9 Jan 2011 23:18:30 -0800 (PST)
Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 6BD273A6935 for ; Sun,  9 Jan 2011 23:18:29 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2933805; Mon, 10 Jan 2011 08:20:38 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 683A423F0290; Mon, 10 Jan 2011 08:20:38 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 10 Jan 2011 08:20:38 +0100
From: "Elwell, John" 
To: Harald Alvestrand 
Date: Mon, 10 Jan 2011 08:20:36 +0100
Thread-Topic: [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at	IETF"
Thread-Index: AcuvPLoRa3tZ4ajTTe+mZ4Lei6TUfABWU/tg
Message-ID: 
References: <4D25AD41.7060306@alvestrand.no>  <4D286E83.9040604@alvestrand.no>
In-Reply-To: <4D286E83.9040604@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" 
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at	IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jan 2011 07:18:31 -0000

=20

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]=20
> Sent: 08 January 2011 14:03
> To: Elwell, John
> Cc: 'dispatch@ietf.org'; rtc-web@alvestrand.no
> Subject: Re: [RTW] Charter proposal: The activity hitherto=20
> known as "RTC-WEB at IETF"
>=20
> On 01/07/11 10:38, Elwell, John wrote:
> > Harald,
> >
> > With one exception, this draft charter does not mention=20
> signalling (SIP/SDP), and I assume it is intended to be out=20
> of scope, although that is not explicitly stated.
> >
> > The one exception is "8) RFC 4574 based Label support for=20
> identifying streams purpose".
> > This is an SDP attribute. How would this be used if SDP is=20
> indeed out of scope? If SDP is in scope, we certainly need=20
> more text describing its relevance.
> There isn't much text in 4574 - the main point of the RFC seems to be=20
> that it's possible to create labels for streams before creating the=20
> stream. Those labels could be independent of the signalling mechanism.
>=20
> The trend I see now is that most APIs and protocols people=20
> define (for=20
> instance Jabber/XMPP, JSON-based descriptions) have some kind=20
> of mapping=20
> to SDP, so SDP-as-a-format may not be so important (I=20
> heartily dislike=20
> multiple things about the specific format), but SDP-as-a-semantic=20
> becomes more important over time, and can't be ignored.
[JRE] RFC 4574 is little more than an SDP syntax (for conveying an applicat=
ion-specific label). As such, if we don't use the SDP syntax, I don't see h=
ow RFC 4574 can apply at all.
The problem we need to solve, if I understand correctly, is for the applica=
tion to instruct the browser what source and sink to use for a given medium=
. For audio, this means telling the browser which microphone and which spea=
ker to use. For video, this means telling the browser which camera to use a=
nd where on the display to render received video. I don't see the relevance=
 of RFC 4574 for achieving this.

John


>=20
>                        Harald
>=20
> =

From singer@apple.com  Mon Jan 10 00:04:52 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6BD28C0F7 for ; Mon, 10 Jan 2011 00:04:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.01
X-Spam-Level: 
X-Spam-Status: No, score=-106.01 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afWuWvMDsoUt for ; Mon, 10 Jan 2011 00:04:51 -0800 (PST)
Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 5C9CB28C0F4 for ; Mon, 10 Jan 2011 00:04:51 -0800 (PST)
Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 373A5C5FFF70; Mon, 10 Jan 2011 00:07:02 -0800 (PST)
X-AuditID: 11807130-b7cb4ae000001037-2e-4d2abe24d294
Received: from [17.72.145.128] (Unknown_Domain [17.72.145.128]) by relay11.apple.com (Apple SCV relay) with SMTP id 1B.00.04151.42EBA2D4; Mon, 10 Jan 2011 00:07:02 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: David Singer 
In-Reply-To: <4D27A4C9.1020107@nostrum.com>
Date: Mon, 10 Jan 2011 09:06:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <60E1BC1A-3BF7-42AD-BC78-9CB652E5240A@apple.com>
References:  <3620438B-EA9D-4459-AAC4-1E02C2ACA45F@apple.com> <4D276A6E.9050607@nostrum.com> <48EA89ED-8044-4537-B79D-44CBEE4532DB@apple.com> <4D27A4C9.1020107@nostrum.com>
To: Adam Roach 
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
Cc: Bernard Aboba , Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] Known encumberances != exhaustive list of encumberances (was Gateways and does anyone think "H.264 for ever"?)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jan 2011 08:04:52 -0000

On Jan 8, 2011, at 0:42 , Adam Roach wrote:

>> Contrast that with someone who believes that they might have a patent =
on Theora.  While it's an open-source codec in development with limited =
deployment, where is the incentive (let alone requirement) to check? A =
statement that Theora needs a license would be unpopular (!), would take =
real time and effort to check (the analysis), and result in bad PR and =
no revenue, even if you win.  On the other hand, if you wait, and then =
someone who is both (a) rich and (b) you don't like or wish to fight =
back against, deploys it, you now have the incentive to check and go =
after it.
>=20
> Google, which has embedded both Theora and VP8 in Chrome, has a $198B =
market cap and $23B of annual revenue.  How large is a company before =
you consider it to have deep enough pockets to bother raiding? I mean, =
if we're talking about software companies, there are only three or so =
that can be legitimately considered "larger" by any financial metric.

You address only one of my points, and answer a strawman.  "IF the =
patent holder's only interest is money THEN why haven't they sued =
Google?". Perhaps they have a cross-license. Perhaps they are in =
negotiation with Google over this or other matters. Perhaps...

>>   But we have to be realistic about what we pursue.
>=20
> How is considering VP8 and/or Theora as a baseline unrealistic? I'm =
not saying either should be a foregone conclusion; I'd like to see a =
well-reasoned discussion around codec selection.

Then we agree;  that's what I want also.

> But I don't think characterizing RF technologies as inherently having =
excessive IPR risk falls into the category of "well-reasoned," even if =
certain licensing entities have engaged in self-serving saber rattling =
on the topic.

The IPR risk varies by codec and how it was developed, and is only =
poorly-correlated with any stated RF status.

> But your implication that we should penalize a technology *because* it =
is not known to be encumbered is exactly the opposite of this.

That's not what I am saying.  I am saying we should be careful of codecs =
that were developed in such a way that their encumbrance status is not =
as clear we might like.


David Singer
Multimedia and Software Standards, Apple Inc.


From peter.musgrave@magorcorp.com  Mon Jan 10 03:20:35 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7334F28C15C for ; Mon, 10 Jan 2011 03:20:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.39
X-Spam-Level: 
X-Spam-Status: No, score=-103.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+h83vCa0v78 for ; Mon, 10 Jan 2011 03:20:34 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A756E28C15A for ; Mon, 10 Jan 2011 03:20:33 -0800 (PST)
Received: by iwn40 with SMTP id 40so20334728iwn.31 for ; Mon, 10 Jan 2011 03:22:47 -0800 (PST)
Received: by 10.42.165.69 with SMTP id j5mr4141610icy.237.1294658566941; Mon, 10 Jan 2011 03:22:46 -0800 (PST)
Received: from [192.168.1.100] ([204.237.32.134]) by mx.google.com with ESMTPS id jv9sm3576314icb.1.2011.01.10.03.22.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 03:22:45 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Peter Musgrave 
In-Reply-To: 
Date: Mon, 10 Jan 2011 06:22:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4D25AD41.7060306@alvestrand.no>  <4D286E83.9040604@alvestrand.no> 
To: "Elwell, John" 
X-Mailer: Apple Mail (2.1082)
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" 
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at	IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jan 2011 11:20:35 -0000

Hi,

I agree with John. The 'label' RFC is essentially syntax.

It seems to me this source/sink issue has some things in common with the =
work in CLUE (formerly maitai) in the sense that it too has to face the =
issue of linking devices with streams...

It may be that they need a common protocol mechanism...

Regards,=20

Peter Musgrave

On 2011-01-10, at 2:20 AM, Elwell, John wrote:

>=20
>=20
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:harald@alvestrand.no]=20
>> Sent: 08 January 2011 14:03
>> To: Elwell, John
>> Cc: 'dispatch@ietf.org'; rtc-web@alvestrand.no
>> Subject: Re: [RTW] Charter proposal: The activity hitherto=20
>> known as "RTC-WEB at IETF"
>>=20
>> On 01/07/11 10:38, Elwell, John wrote:
>>> Harald,
>>>=20
>>> With one exception, this draft charter does not mention=20
>> signalling (SIP/SDP), and I assume it is intended to be out=20
>> of scope, although that is not explicitly stated.
>>>=20
>>> The one exception is "8) RFC 4574 based Label support for=20
>> identifying streams purpose".
>>> This is an SDP attribute. How would this be used if SDP is=20
>> indeed out of scope? If SDP is in scope, we certainly need=20
>> more text describing its relevance.
>> There isn't much text in 4574 - the main point of the RFC seems to be=20=

>> that it's possible to create labels for streams before creating the=20=

>> stream. Those labels could be independent of the signalling =
mechanism.
>>=20
>> The trend I see now is that most APIs and protocols people=20
>> define (for=20
>> instance Jabber/XMPP, JSON-based descriptions) have some kind=20
>> of mapping=20
>> to SDP, so SDP-as-a-format may not be so important (I=20
>> heartily dislike=20
>> multiple things about the specific format), but SDP-as-a-semantic=20
>> becomes more important over time, and can't be ignored.
> [JRE] RFC 4574 is little more than an SDP syntax (for conveying an =
application-specific label). As such, if we don't use the SDP syntax, I =
don't see how RFC 4574 can apply at all.
> The problem we need to solve, if I understand correctly, is for the =
application to instruct the browser what source and sink to use for a =
given medium. For audio, this means telling the browser which microphone =
and which speaker to use. For video, this means telling the browser =
which camera to use and where on the display to render received video. I =
don't see the relevance of RFC 4574 for achieving this.
>=20
> John
>=20
>=20
>>=20
>>                       Harald
>>=20
>>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From pkyzivat@cisco.com  Mon Jan 10 07:42:17 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8567D3A67FC for ; Mon, 10 Jan 2011 07:42:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.477
X-Spam-Level: 
X-Spam-Status: No, score=-110.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyvrnP5A-DaP for ; Mon, 10 Jan 2011 07:42:16 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 658303A67ED for ; Mon, 10 Jan 2011 07:42:15 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEANO3Kk1AZnwN/2dsb2JhbACkQXOjMJdihUwEhGeGI4Mg
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2011 15:44:29 +0000
Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0AFiTwR015519 for ; Mon, 10 Jan 2011 15:44:29 GMT
Message-ID: <4D2B295D.9020209@cisco.com>
Date: Mon, 10 Jan 2011 10:44:29 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4D25AD41.7060306@alvestrand.no>		<4D286E83.9040604@alvestrand.no>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at	IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jan 2011 15:42:17 -0000

On 1/10/2011 6:22 AM, Peter Musgrave wrote:
> Hi,
>
> I agree with John. The 'label' RFC is essentially syntax.
>
> It seems to me this source/sink issue has some things in common with the work in CLUE (formerly maitai) in the sense that it too has to face the issue of linking devices with streams...
>
> It may be that they need a common protocol mechanism...

This issue is broader than that too.

To date with sip we have mostly been assuming degenerate cases where 
there is only one source/sink for every media stream, or that if there 
are more then it is policy of the user of the device to make the 
mapping. (E.g. choosing to use the headset rather than the handset or 
speaker.) Any time you want to give another party a say in this decision 
you need a way to signal it.

	Thanks,
	Paul

> Regards,
>
> Peter Musgrave
>
> On 2011-01-10, at 2:20 AM, Elwell, John wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>>> Sent: 08 January 2011 14:03
>>> To: Elwell, John
>>> Cc: 'dispatch@ietf.org'; rtc-web@alvestrand.no
>>> Subject: Re: [RTW] Charter proposal: The activity hitherto
>>> known as "RTC-WEB at IETF"
>>>
>>> On 01/07/11 10:38, Elwell, John wrote:
>>>> Harald,
>>>>
>>>> With one exception, this draft charter does not mention
>>> signalling (SIP/SDP), and I assume it is intended to be out
>>> of scope, although that is not explicitly stated.
>>>>
>>>> The one exception is "8) RFC 4574 based Label support for
>>> identifying streams purpose".
>>>> This is an SDP attribute. How would this be used if SDP is
>>> indeed out of scope? If SDP is in scope, we certainly need
>>> more text describing its relevance.
>>> There isn't much text in 4574 - the main point of the RFC seems to be
>>> that it's possible to create labels for streams before creating the
>>> stream. Those labels could be independent of the signalling mechanism.
>>>
>>> The trend I see now is that most APIs and protocols people
>>> define (for
>>> instance Jabber/XMPP, JSON-based descriptions) have some kind
>>> of mapping
>>> to SDP, so SDP-as-a-format may not be so important (I
>>> heartily dislike
>>> multiple things about the specific format), but SDP-as-a-semantic
>>> becomes more important over time, and can't be ignored.
>> [JRE] RFC 4574 is little more than an SDP syntax (for conveying an application-specific label). As such, if we don't use the SDP syntax, I don't see how RFC 4574 can apply at all.
>> The problem we need to solve, if I understand correctly, is for the application to instruct the browser what source and sink to use for a given medium. For audio, this means telling the browser which microphone and which speaker to use. For video, this means telling the browser which camera to use and where on the display to render received video. I don't see the relevance of RFC 4574 for achieving this.
>>
>> John
>>
>>
>>>
>>>                        Harald
>>>
>>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

From Even.roni@huawei.com  Mon Jan 10 08:35:32 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FD03A680B for ; Mon, 10 Jan 2011 08:35:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.345
X-Spam-Level: 
X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=-1.849, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thRHYaSxw-T8 for ; Mon, 10 Jan 2011 08:35:31 -0800 (PST)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 352E13A67FA for ; Mon, 10 Jan 2011 08:35:31 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LET00CXRFIM60@szxga05-in.huawei.com> for dispatch@ietf.org; Tue, 11 Jan 2011 00:37:34 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LET00J3DFILZJ@szxga05-in.huawei.com> for dispatch@ietf.org; Tue, 11 Jan 2011 00:37:34 +0800 (CST)
Received: from YOUR6108 (bzq-79-180-15-157.red.bezeqint.net [79.180.15.157]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0LET00LLAFIE1G@szxml02-in.huawei.com>; Tue, 11 Jan 2011 00:37:33 +0800 (CST)
Date: Mon, 10 Jan 2011 18:37:30 +0200
From: Roni Even 
In-reply-to: <4D2B295D.9020209@cisco.com>
To: 'Paul Kyzivat' , dispatch@ietf.org
Message-id: <000c01cbb0e4$b64e54d0$22eafe70$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: he
Content-transfer-encoding: 7BIT
Thread-index: Acuw3VbBaW4bXv/eSNuCLFgqtnS4PAABvtgg
References: <4D25AD41.7060306@alvestrand.no>  <4D286E83.9040604@alvestrand.no>   <4D2B295D.9020209@cisco.com>
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at	IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jan 2011 16:35:32 -0000

Hi,
Look at RFC4796 that defines the content attribute that has the semantics of
the stream. The semantics can be extended. What it lacks is the expected
behavior that can be specified in a profile. 
Roni Even

> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Monday, January 10, 2011 5:44 PM
> To: dispatch@ietf.org
> Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto
> known as "RTC-WEB at IETF"
> 
> 
> 
> On 1/10/2011 6:22 AM, Peter Musgrave wrote:
> > Hi,
> >
> > I agree with John. The 'label' RFC is essentially syntax.
> >
> > It seems to me this source/sink issue has some things in common with
> the work in CLUE (formerly maitai) in the sense that it too has to face
> the issue of linking devices with streams...
> >
> > It may be that they need a common protocol mechanism...
> 
> This issue is broader than that too.
> 
> To date with sip we have mostly been assuming degenerate cases where
> there is only one source/sink for every media stream, or that if there
> are more then it is policy of the user of the device to make the
> mapping. (E.g. choosing to use the headset rather than the handset or
> speaker.) Any time you want to give another party a say in this
> decision
> you need a way to signal it.
> 
> 	Thanks,
> 	Paul
> 
> > Regards,
> >
> > Peter Musgrave
> >
> > On 2011-01-10, at 2:20 AM, Elwell, John wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> >>> Sent: 08 January 2011 14:03
> >>> To: Elwell, John
> >>> Cc: 'dispatch@ietf.org'; rtc-web@alvestrand.no
> >>> Subject: Re: [RTW] Charter proposal: The activity hitherto
> >>> known as "RTC-WEB at IETF"
> >>>
> >>> On 01/07/11 10:38, Elwell, John wrote:
> >>>> Harald,
> >>>>
> >>>> With one exception, this draft charter does not mention
> >>> signalling (SIP/SDP), and I assume it is intended to be out
> >>> of scope, although that is not explicitly stated.
> >>>>
> >>>> The one exception is "8) RFC 4574 based Label support for
> >>> identifying streams purpose".
> >>>> This is an SDP attribute. How would this be used if SDP is
> >>> indeed out of scope? If SDP is in scope, we certainly need
> >>> more text describing its relevance.
> >>> There isn't much text in 4574 - the main point of the RFC seems to
> be
> >>> that it's possible to create labels for streams before creating the
> >>> stream. Those labels could be independent of the signalling
> mechanism.
> >>>
> >>> The trend I see now is that most APIs and protocols people
> >>> define (for
> >>> instance Jabber/XMPP, JSON-based descriptions) have some kind
> >>> of mapping
> >>> to SDP, so SDP-as-a-format may not be so important (I
> >>> heartily dislike
> >>> multiple things about the specific format), but SDP-as-a-semantic
> >>> becomes more important over time, and can't be ignored.
> >> [JRE] RFC 4574 is little more than an SDP syntax (for conveying an
> application-specific label). As such, if we don't use the SDP syntax, I
> don't see how RFC 4574 can apply at all.
> >> The problem we need to solve, if I understand correctly, is for the
> application to instruct the browser what source and sink to use for a
> given medium. For audio, this means telling the browser which
> microphone and which speaker to use. For video, this means telling the
> browser which camera to use and where on the display to render received
> video. I don't see the relevance of RFC 4574 for achieving this.
> >>
> >> John
> >>
> >>
> >>>
> >>>                        Harald
> >>>
> >>>
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5774 (20110110) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5774 (20110110) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 5774 (20110110) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 


From ted.ietf@gmail.com  Mon Jan 10 11:17:41 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4073A6B0C for ; Mon, 10 Jan 2011 11:17:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.181
X-Spam-Level: 
X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.418,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfdnwAqGBmKA for ; Mon, 10 Jan 2011 11:17:39 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 56C4A3A6B0D for ; Mon, 10 Jan 2011 11:17:39 -0800 (PST)
Received: by qwi2 with SMTP id 2so4416515qwi.31 for ; Mon, 10 Jan 2011 11:19:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ql5/C2C2IM4Z4hz90DM+nff8YSgy2ElksQ5xfpmC3bY=; b=f4BcYAMaHQUsxu2Oko9/UgBXIiEMDEYRmEDG4LAzmF3oCLV6WCLrRgT+E8RpSw2VHh 7gTnUu0GudAALPln3Bsfg0aoggrdo/PLA3TCYBlCgPxV9FyvF83ov6WHeF5Pv5GeSNHv 6Z/71NhwFHH5dMQsQwgI0B8D4VgqOldCGr7ng=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EswGNnd6PHPuvsFPB6MFaLKR0nc1f4f/suUriYY2b/s8WEdkuWWLhnOE2U+bZfJk2j 5b6cMapoVDVVx9H9f/z4fP7TiWcdqcLLknyUBrcloEEHgZ89gTc8LUcNTWZeiUJ3SVYj uPz795hvSq9Qyz5RTI7yNaqbE90ODk31l34a4=
MIME-Version: 1.0
Received: by 10.229.215.9 with SMTP id hc9mr8679731qcb.117.1294687193525; Mon, 10 Jan 2011 11:19:53 -0800 (PST)
Received: by 10.229.230.138 with HTTP; Mon, 10 Jan 2011 11:19:53 -0800 (PST)
In-Reply-To: <4D27157F.6050701@alvestrand.no>
References: <4D25AD41.7060306@alvestrand.no>  <4D27157F.6050701@alvestrand.no>
Date: Mon, 10 Jan 2011 11:19:53 -0800
Message-ID: 
From: Ted Hardie 
To: Harald Alvestrand 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jan 2011 19:17:41 -0000

Hi Harald,

Some replies in-line.

On Fri, Jan 7, 2011 at 5:30 AM, Harald Alvestrand  wr=
ote:
> On 01/06/11 19:43, Ted Hardie wrote:
>>
>> Hi Harald,
>>
>> Thanks for putting this together; some discussion in-line.
>>
>> On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand
>> =A0wrote:
>>>
>>> This is the first of 3 messages going to the DISPATCH list (in the hope
>>> of
>>> keeping discussions somewhat organized).
>>>
>>> This is the draft of a charter for an IETF working group to consider th=
e
>>> subject area of "Real time communication in the Web browser platform".
>>> This
>>> is one of a paired set of activities, the other one being a W3C activit=
y
>>> (either within an existing WG or in a new WG) that defines APIs to this
>>> functionality.
>>>
>>> The two other messages will contain the W3C proposed charter and a
>>> kickoff
>>> for what's usually the most distracting topic in any such discussion: T=
he
>>> name of the group.
>>> Without further ado:
>>>
>>> -------------------------------------
>>>
>>> Version: 2
>>>
>>> Possible Names:
>>> 
>>>
>>> Body:
>>>
>>> Many implementations have been made that use a Web browser to support
>>> interactive communications directly between users including voice, vide=
o,
>>> collaboration and gaming, but until now, such applications have require=
d
>>> the
>>> installation of nonstandard plugins and browser extensions. There is a
>>> desire to standardize such functionality, so that this type of
>>> application
>>> can be run in any compatible browser.
>>>
>> In at least some of the contexts identified above, there is a
>> long-lived identifier
>> associated with the individuals who will have interactive
>> communications; that is,
>> there is a context-specific presence architecture in addition to the
>> implementation-specific
>> real-time communications. =A0Though the text below occasionally says
>> "users",
>> there does not seem to be any work being defined that would touch on thi=
s.
>> I see that in the last sentence you explicitly rule it out of scope.
>> Without this,
>> this seems to be limited to an architecture where a mediating server
>> provides
>> the initial signaling path. =A0If that is the scope, I think that should=
 be
>> made
>> explicit as a design statement, not inferred from the lack of presence.
>
> I think what you mean is that at this level, we're not taking a position =
on
> what an "user" is, or whether the concept of "user" even has meaning for =
the
> application (think chatroulette for one example of an application where
> there are no long-lived user identifiers).
>
> I would certainly agree that this is a reasonable restriction of our work=
,
> and would welcome suggested text on how to write that into the charter.
>>>

How about:

Many implementations have been made that use a Web browser to support
direct, interactive communications, including voice, video, collaboration, =
and
gaming.  In these implementations, the web server acts as the signaling
path between these applications, using locally significant identifiers to s=
et
up the association.  Up till now, such applications have typically
required the installation of plugins or non-standard browser extensions.
There is a desire to standardize this functionality, so that this type
of application
can be run in any compatible browser.

>>> Traditionally, the W3C has defined API and markup languages such as HTM=
L
>>> that work in conjunction with with the IETF over the wire protocols suc=
h
>>> as
>>> HTTP to allow web browsers to display media that does not have real tim=
e
>>> interactive constraints with another human.
>>>
>>> The W3C and IETF plan to collaborate together in their traditional way =
to
>>> meet the evolving needs of browsers. Specifically the IETF will provide=
 a
>>> set of on the wire protocols, including RTP, to meet the needs on
>>> interactive communications, and the W3C will define the API and markup =
to
>>> allow web application developers to control the on the wire protocols.
>>> This
>>> will allow application developers =A0to write applications that run in =
a
>>> browser and facilitate interactive communications between users for voi=
ce
>>> and video communications, collaboration, and gaming.
>>>
>>> This working group will select and define a minimal set of protocols th=
at
>>> will enable browsers to:
>>>
>>> * have interactive real time voice and video between users using RTP
>>> * interoperate with compatible voice and video systems that are not web
>>> based
>>> * support direct flows of non RTP application data between browsers for
>>> collaboration and gaming applications
>>>
>> Okay "direct flows of non-RTP application data" goes beyond scope creep;
>> to satisfy this completely, we are talking an end-point-to-end-point
>> tunnel,
>> which will run afoul of a lot of folks who dearly love packet inspection=
.
>> =A0I
>> would say that it would be best to first tackle the voice/video bits and
>> then
>> tackle this problem. =A0Re-charter the WG to cover this, in other words,
>> after
>> the first bit is done.
>>
>> I also note that you're using "between browsers", rather than "among
>> browsers".
>> Is it intended that this facility should allow for multi-party
>> communication?
>> Leaving aside the non-RTP issues, that would add floor control, media
>> mixing,
>> etc. to the task list. =A0Again, I think it should either be explicitly
>> in-scope or out-of-scope.
>
> I did not intend "between" to indicate that there were only two parties, =
but
> think that we're building point-to-point communications, not N-to-N.
>
> In one interpretation of the distinction .... I think we're standardizing
> point-to-point communications at this time, since all the proven-viable
> multipoint communication applications have been built out of point-to-poi=
nt
> links rather than using underlying multipoint technologies like multicast=
.
>
> In another interpretation ... I think we should limit ourselves to provid=
ing
> a toolbox. I think floor control (except for possibly providing the
> signalling channels floor control needs) is out of scope; MAITAI may be a
> better place to discuss media mixing.
>

So, maybe this would be clearer if I asked it in a different way.  Are
you thinking of something like websockets run between two peers?
Or are you thinking of layered tunnel model?

>>> Fortunately very little development of new protocol at IETF is required
>>> for
>>> this, only selection of existing protocols and selection of minimum
>>> capabilities to ensure interoperability. The following protocols are
>>> candidates for including in the profile set:
>>>
>>> 1) RTP/ RTCP
>>>
>>> 2) a baseline audio codec for high quality interactive audio. Opus
>>> will be considered as one of the candidates
>>>
>>> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
>>> will be considered
>>>
>>> 4) a baseline video codec. H.264 and VP8 will be considered
>>>
>>> 5) Diffserv based QoS
>>>
>>> 6) NAT traversal using ICE
>>>
>> The ICE spec is clear that the NAT traversal it provides does not
>> help establish the signaling between agents. =A0For this browser-to-brow=
ser
>> mechanism, if we are limiting this to situations where a mediating web
>> server
>> provides the initial signaling path, that's okay. =A0If there is a
>> different model, though,
>> we may need additional tools here.
>
> If we can make the mediating-web-server model work, I think we have succe=
ss;
> if we can't make it work, we have a failure. So obviously that's my first
> priority. What text changes do you think are needed?

If the text I suggested above clarifying that this is mediating-web-server
works for you, I don't think additionally text is needed here.

>>>
>>> 7) RFC 4833 based DTMF transport
>>>
>>> 8) RFC 4574 based Label support for identifying streams purpose
>>>
>>> 9) Secure RTP and keying
>>>
>>> 10) support for IPv4, IPv6 and dual stack browsers
>>>
>>> The working group will cooperate closely with the W3C activity that
>>> specifies a semantic level API that allows the control and manipulation
>>> of
>>> all the functionality above. In addition, the API needs to communicate
>>> state
>>> information and events about what is happening in the browser that to
>>> applications running in the browser.
>>
>> I think the sentence above has some extra words; is the browser talking
>> to application running in the browser? =A0Can it be re-phrased?
>
> I think there's an extra "that" - when an event happens at the
> communications interface, this event needs to be propagated over the API =
to
> the Javascript that is running in a Web page - that Web page is what I've
> been thinking of as "the application". (There are other moves around that
> want to run "web pages" in other contexts than a currently open tab in a
> broswer, but for the moment, "a tab in a browser", or even "a set of tabs=
 in
> a browser" is a reasonable synonym for "application", I think).
>>
>> These events and state need to include
>>>
>>> information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics,
>>> state
>>> of DTLS/SRTP, =A0and signalling state.
>>>
>>> The following topics will be out of scope for the initial phase of the =
WG
>>> but could be added after a recharter: RTSP, RSVP, NSIS, LOST,
>>> Geolocation,
>>> IM& =A0Presence, NSIS, Resource Priority,
>>>
>>> Milestones:
>>>
>>> February 2011 Candidate "sample" documents circulated to DISPATCH
>>>
>>> March 2011 BOF at IETF Prague
>>>
>>> April 2011 WG charter approved by IESG. Chosen document sets adopted as
>>> WG
>>> documents
>>>
>>> May 2011 Functionality to include and main alternative protocols
>>> identified
>>>
>>> July 2011 IETF meeting
>>>
>>> Aug 2011 Draft with text reflecting agreement of what the protocol set
>>> should be
>>>
>>> Nov 2010 Documentation specifying mapping of protocol functionality to
>>> W3C-specified API produced
>>>
>>> Dec 2011 Protocol set specification to IESG
>>>
>>> April 2012 API mapping document to IESG
>>>
>> Pretty aggressive, given the number of moving parts. =A0It's also not
>> clear why the November 2011 doc (I assume 2010 is a typo) is
>> done in the IETF, rather than the W3C. =A0Or is it joint work?
>
> More or less done this way at random. I think of this as joint work;
> documents may move between the organizations as we progress, but I'm not
> sure how the W3C document model works yet.
>
>
I think that we need to be a bit more careful on the
dependencies, as it has not been my experience that joint
work has resulted in a congruent set of people working on them
in the two organizations.   Can we make the deliverable for
the November 2011 doc the release of a draft, with a note it
is intended as a substrate to the W3C work?  That would
make the W3C work have a dependency on this draft delivery.

regards,

Ted Hardie

From petithug@acm.org  Mon Jan 10 14:17:21 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83BE3A67AE for ; Mon, 10 Jan 2011 14:17:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.754
X-Spam-Level: 
X-Spam-Status: No, score=-101.754 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LVeDhXSn5ia for ; Mon, 10 Jan 2011 14:16:52 -0800 (PST)
Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 8FC513A672E for ; Mon, 10 Jan 2011 14:16:52 -0800 (PST)
Received: by server.implementers.org (Postfix, from userid 1001) id 80A4611BC401E; Mon, 10 Jan 2011 22:19:07 +0000 (UTC)
Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id AE17711BC401C for ; Mon, 10 Jan 2011 22:19:06 +0000 (UTC)
Message-ID: <4D2B85D9.8010003@acm.org>
Date: Mon, 10 Jan 2011 14:19:05 -0800
From: Marc Petit-Huguenin 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: "dispatch@ietf.org" 
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [dispatch] VIPR Charter
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Jan 2011 22:17:22 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On the advice of the DISPATCH chairs, I am reposting below the latest version of
the VIPR charter for additional feedback.

They are not considered as candidates for WG documents under this charter, but
FYI the ViPR drafts were last updated in October 2010, and will probably be
updated again before Prague:

http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-overview-04.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-reload-usage-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-pvp-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-sip-antispam-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-vap-03.txt

Thanks.

- ------------------------------------------------------------------------

VIPR Charter Proposal (Version 4)

WG Name:  Verification Involving PSTN Reachability (VIPR)

There are two globally deployed address spaces for communications used
by more than a billion people daily - phone numbers and DNS rooted
address such as web servers and email addresses. The inter-domain
signaling design of SIP is primarily designed for email style addresses
yet a large percentage of SIP deployments mostly use phone numbers for
identifying users, thus DNS lookups are not sufficient. Other approaches
such as public ENUM are not sufficient due to lack of widespread
deployment for non-technical reasons - i.e., the involvement of
government and service provider administrative entities needing to
approve and populate the registries.  Private federations have been
established to workaround the issue, however, that solution is not
scalable. The goal of this working group is to enable inter-domain
communications over the the Internet, using protocols such as SIP,
while still allowing people to use phone numbers to identify the person
with whom they wish to communicate.

The VIPR WG will develop a peer to peer based approach to finding
domains that claim to be responsible for a given phone number
to mitigate the involvement of centralized entities to avoid some of
the issues encountered by past attempts to support SIP inter-domain
communications. Validation protocols will be developed to ensure a
reasonable likelihood that a given domain actually is responsible for
the phone number. In this context, "responsible" means an
administrative domain, which is at least one of the domains, to which
a PSTN call to this phone number would be routed. Once the domain
responsible for the phone number is found, existing protocols, such
as SIP, can be used for inter-domain communications.

Some validation protocols may be based on knowledge gathered around a
PSTN call; for example, the ability to prove a call was received over
the PSTN based on start and stop times. Other validation schemes, such
as examining fingerprints or watermarking of PSTN media to show that a
domain received a particular PSTN phone call, may also be considered by
the working group. This validation will be accomplished using publicly
available open interfaces to the PSTN, so the validation can be
performed by any domain wishing to participate.  The WG will select and
standardize at least one validation scheme.

The validation mechanism requires a domain to gather and maintain
information related to PSTN calls.  This information is used by call
agents such as phones, SBCs and IP PBXs to route calls.  The WG will
define a client-server protocol between these call agents and the entity
within a domain that maintains the information.

To help mitigate SPAM issues when using SIP between domains, the WG will
define a mechanism to enable one domain to check that incoming SIP
messages are coming from a validated phone number.  A phone number is
considered validated if it is coming from a domain to which the calling
domain had previously successfully placed a PSTN call.  The working
group will define new SIP headers and option tags, as necessary, to
enable this.

The essential characteristic of VIPR is establishing authentication by
PSTN reachability when it is not possible to use a direct reference to
ENUM databases or other direct assertions of PSTN number
ownership. Elements such as public ENUM easily coexist with VIPR but no
direct interaction with ENUM will be required.  The solution set defined
by this WG will be incrementally deployable using only existing
interfaces to the PSTN.  No changes will be required to existing PSTN
capabilities, no new database access is needed nor is any new support
from PSTN service providers required.

The WG will produce the following deliverables:

1) A document describing the requirements, problem statement and
architectural approach to support SIP inter-domain communications.
2) A document describing the use of the p2psip protocol (RELOAD) as
applied to this problem space.
3) A document defining a scheme for validating the phone numbers using
publicly available open interfaces to the PSTN.
4) A document defining client-server protocol between call agents and the
entity within a domain that gathers and maintains information related to
PSTN calls.
5) A document describing a mechanism to mitigate SPAM issues.

The working group will carefully coordinate with the security area, O&M
area, as well as the appropriate RAI WGs such as sipcore and p2psip.

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk0rhdIACgkQ9RoMZyVa61c3rACeIZEoXE5f7+JlqL15Pg2ABeBP
ImAAmQHK60c9Tcf6/tME+fSbWJRZOSe6
=Spko
-----END PGP SIGNATURE-----

From R.Jesske@telekom.de  Tue Jan 11 00:08:07 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FE63A69FB for ; Tue, 11 Jan 2011 00:08:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.886
X-Spam-Level: 
X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.362,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzrehZFeUps5 for ; Tue, 11 Jan 2011 00:08:06 -0800 (PST)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 318B63A69F8 for ; Tue, 11 Jan 2011 00:08:06 -0800 (PST)
Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 11 Jan 2011 09:10:04 +0100
Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.174]) by he110890 ([10.134.92.131]) with mapi; Tue, 11 Jan 2011 09:09:56 +0100
From: 
To: 
Date: Tue, 11 Jan 2011 09:09:54 +0100
Thread-Topic: Reason in Responses
Thread-Index: AcuxZu2H+D6GCH7RR5emN5pGIRuqEw==
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D85D43204@HE111648.emea1.cds.t-internal.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D85D43204HE111648emea1cd_"
MIME-Version: 1.0
Subject: [dispatch] Reason in Responses
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jan 2011 08:08:07 -0000

--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D85D43204HE111648emea1cd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,
due to the expiry of the drafts for Reason in responses I updated the draft=
s concerning the discussions we had.
I'm still waiting for an indication how to proceed, either as individual dr=
aft or as normal WI.

http://www.ietf.org/internet-drafts/draft-jesske-dispatch-reason-in-respons=
es-03.txt

This is the draft itself. I have added a section for requirements again, as=
 it was proposed from a couple of people. The requirements section is very =
short and  exists of two requirements.

http://www.ietf.org/internet-drafts/draft-jesske-dispatch-req-reason-in-res=
ponses-02.txt

This draft is the origin draft and includes the requirements and reasoning.=
 Therefore I have updated it only for documentation reasons.

comments?

Thanks and Best Regards


Roland




--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D85D43204HE111648emea1cd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear all,


due to the expiry of the drafts for Reason in responses I updated the =
drafts concerning the discussions we had.


I'm still waiting for an indication how to proceed, either as individu=
al draft or as normal WI.


 



 


This is the draft itself. I have added a section for requirements agai=
n, as it was proposed from a couple of people. The requirements section is =
very short and  exists of two requirements.


 



 


This draft is the origin draft and includes the requirements and reaso=
ning. Therefore I have updated it only for documentation reasons.


 


comments? 


 


Thanks and Best Regards 


 


 


Roland 


 


 


 





--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D85D43204HE111648emea1cd_--

From salvatore.loreto@ericsson.com  Tue Jan 11 02:05:53 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574623A6A13 for ; Tue, 11 Jan 2011 02:05:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.553
X-Spam-Level: 
X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwN3W7YWT9vd for ; Tue, 11 Jan 2011 02:05:52 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 57A713A63EB for ; Tue, 11 Jan 2011 02:05:52 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-cc-4d2c2c075395
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 59.57.23694.70C2C2D4; Tue, 11 Jan 2011 11:08:07 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Tue, 11 Jan 2011 11:08:07 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 5BC8A251F	for ; Tue, 11 Jan 2011 12:08:07 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1FF55504FA	for ; Tue, 11 Jan 2011 12:08:07 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A4580504AA	for ; Tue, 11 Jan 2011 12:08:06 +0200 (EET)
Message-ID: <4D2C2C06.90104@ericsson.com>
Date: Tue, 11 Jan 2011 11:08:06 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4D25AE32.1020205@alvestrand.no>			<04BD8059-3B89-4F31-88CA-70F4D83ED553@americafree.tv>	<76C27DF8-52D0-47A5-A9D3-C4511D3250AE@bbn.com>	<4D263F13.7040907@mozilla.com>	 <2ECE2C8F-0708-4CB2-95AE-A1569AB28B42@bbn.com>
In-Reply-To: <2ECE2C8F-0708-4CB2-95AE-A1569AB28B42@bbn.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] [RTW] Name discussion: What is the name of the WG that does the RTC-Web stuff?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jan 2011 10:05:53 -0000

On 1/7/11 12:09 AM, Richard L. Barnes wrote:
> +1 now transferred to BRAVO
+1


From christer.holmberg@ericsson.com  Tue Jan 11 06:21:50 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6680A28C17B for ; Tue, 11 Jan 2011 06:21:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.433
X-Spam-Level: 
X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t14m2E+anT5K for ; Tue, 11 Jan 2011 06:21:49 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 038F928C0F0 for ; Tue, 11 Jan 2011 06:21:48 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-99-4d2c68048777
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FA.01.23694.4086C2D4; Tue, 11 Jan 2011 15:24:04 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.33]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 11 Jan 2011 15:24:04 +0100
From: Christer Holmberg 
To: Harald Alvestrand , "rtc-web@alvestrand.no" , "'dispatch@ietf.org'" 
Date: Tue, 11 Jan 2011 15:24:02 +0100
Thread-Topic: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
Thread-Index: AcuuAPfbmlEnW+qFStuoP3WFYdLZ3QDmh3hg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850A227DD912@ESESSCMS0356.eemea.ericsson.se>
References: <4D25AD41.7060306@alvestrand.no> <9AFF6B7A-11DF-4111-B0E7-D4BE6C454944@americafree.tv> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jan 2011 14:21:50 -0000

Hi,

I have some comments/questions on the proposed charter.

GENERAL:
--------

In my opinion it is good that the charter lists tasks that have to be solve=
d, but I don't think the charter should specify the technical solutions.

For example, rather than saying "RFC 4833 based DTMF transport" it should s=
ay "DTMF transport".

Because, we haven't discussed different DTMF transport mechanisms, and I do=
n't think we shall discuss them as part as the charter discussion.

The same comment applies to NAT traversal, identification of media stream p=
urposes etc.

Similar, I don't think the charter shall list different codecs, but only sa=
y that the intention is to choose a baseline codec for audio and video.


NEGOTIATION:
------------

The charter talks about baseline codecs and transport (RTP/RTCP). But, I th=
ink it shall also cover the possibility to negotiate the usage of other cod=
ecs and transports.


INTEROPERABILITY:
-----------------

The charter says:

"interoperate with compatible voice and video systems that are not web base=
d"

And, later a baseline codec for PSTN interoperability is mentioned.

But, interoperability is much more than having a codec. You will need some =
"gateway" that performs mapping between the web based system and the non-we=
b based system. Is the working group supposed to define such mapping?


QOS:
----

What is the thinking behind the addition of DiffServ?



W3C API:
--------

The charter seems to put requirements on the W3C API. In particular, it tal=
ks about "signalling state". What is that?



FUTURE WORK:
------------

If we are going to list potential future work, I would like to add "connect=
ion control" to the list.


Regards,

Christer

From richard@shockey.us  Tue Jan 11 08:21:47 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C80F28C2D7 for ; Tue, 11 Jan 2011 08:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.742
X-Spam-Level: 
X-Spam-Status: No, score=-101.742 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MxCPtynGF0y for ; Tue, 11 Jan 2011 08:21:43 -0800 (PST)
Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 456183A6A49 for ; Tue, 11 Jan 2011 08:21:43 -0800 (PST)
Received: (qmail 18157 invoked by uid 0); 11 Jan 2011 16:24:00 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 11 Jan 2011 16:24:00 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=jQfvCNzb7I04p4PSJeFCeBt6kDyhKxvrfbxM2zhbyTbjdLDzJsj87M42uq7hBHrOXGfD4d1ump1c1Rxr1jKk8y3bBU2mNvsDXxcNmoexsZjRPS+pBRWf59W1F8TmNP2H;
Received: from pool-173-79-200-247.washdc.fios.verizon.net ([173.79.200.247] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pch0p-0005W4-OZ; Tue, 11 Jan 2011 09:24:00 -0700
From: "Richard Shockey" 
To: , 
Date: Tue, 11 Jan 2011 11:23:57 -0500
Message-ID: <014e01cbb1ab$f356d830$da048890$@us>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_014F_01CBB182.0A80D030"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acuxq/KbagRQnPNeSGOIllp3Z4bErg==
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.200.247 authed with richard@shockey.us}
Subject: [dispatch] The SIP Forum announces the SIPNOC conference
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jan 2011 16:21:47 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_014F_01CBB182.0A80D030
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


The SIP Forum Launches SIPNOC -- SIP Network Operators Conference -- for the
Worldwide Service Provider Community


New two-day educational conference for service providers to focus on how to
"make SIP work in the network" and address the key operational issues facing
SIP in today's telecom world


NORTH ANDOVER, MA (January 11, 2011) - The SIP Forum announced today the SIP
Network Operators Conference (SIPNOC), a new annual conference for the
international service provider community. The two-day conference will bring
together the leading technical minds from the telecommunications industry to
learn, discuss and formulate new ideas and strategies concerning the
challenges and opportunities for SIP-based carrier services in fixed and
mobile IP network environments. Unlike other events, this conference is for
SIP network operations personnel, such as NOC engineers, instead of a
high-level conference for executives. The first SIPNOC 2011 conference will
be held at the Hyatt Dulles Hotel in Herndon, VA April 25 -27, 2011. The
event website is located at www.sipnoc.org.

 

http://www.sipforum.org/content/view/372/43/

Richard Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<  mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http//www.sipforum.org

 


------=_NextPart_000_014F_01CBB182.0A80D030
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















The SIP Forum Launches =
SIPNOC -- SIP
Network Operators Conference -- for the Worldwide Service Provider =
Community



New two-day educational =
conference
for service providers to focus on how to “make SIP work in the =
network”
and address the key operational issues facing SIP in today’s =
telecom
world



NORTH ANDOVER, MA (January 11, 2011) - The SIP Forum announced =
today
the SIP Network Operators Conference (SIPNOC), a new annual conference =
for the
international service provider community. The two-day conference will =
bring
together the leading technical minds from the telecommunications =
industry to
learn, discuss and formulate new ideas and strategies concerning the =
challenges
and opportunities for SIP-based carrier services in fixed and mobile IP =
network
environments. Unlike other events, this conference is for SIP network
operations personnel, such as NOC engineers, instead of a high-level =
conference
for executives. The first SIPNOC 2011 conference will be held at the =
Hyatt
Dulles Hotel in Herndon, VA April 25 -27, 2011. The event website is =
located at
www.sipnoc.org.



 



http://www.sipforum.org/content/view/372/43/=




Richard =
Shockey

Shockey Consulting

Chairman of the Board of Directors SIP Forum

PSTN Mobile: +1 703.593.2683

<mailto:richard(at)shockey.us>

skype-linkedin-facebook: rshockey101

http//www.sipforum.org



 









------=_NextPart_000_014F_01CBB182.0A80D030--


From gonzalo.camarillo@ericsson.com  Tue Jan 11 10:50:00 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45343A69A1 for ; Tue, 11 Jan 2011 10:50:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.606
X-Spam-Level: 
X-Spam-Status: No, score=-106.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0nNiORYUP9w for ; Tue, 11 Jan 2011 10:49:59 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id EC7483A681B for ; Tue, 11 Jan 2011 10:49:58 -0800 (PST)
X-AuditID: c1b4fb3d-b7b89ae0000036a3-10-4d2ca6df6cc7
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 99.18.13987.FD6AC2D4; Tue, 11 Jan 2011 19:52:15 +0100 (CET)
Received: from [131.160.126.193] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Tue, 11 Jan 2011 19:52:14 +0100
Message-ID: <4D2CA6DE.2050902@ericsson.com>
Date: Tue, 11 Jan 2011 20:52:14 +0200
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: DISPATCH 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: [dispatch] Fwd: [clue] WG Action: ControLling mUltiple streams for tElepresence (clue)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jan 2011 18:50:00 -0000

FYI: the CLUE WG has been created.

Cheers,

Gonzalo

-------- Original Message --------
Subject: [clue] WG Action: ControLling mUltiple streams for
tElepresence	(clue)
Date: Tue, 11 Jan 2011 19:17:28 +0100
From: IESG Secretary 
To: IETF Announcement list 
CC: clue@ietf.org 

A new IETF working group has been formed in the Real-time Applications and
Infrastructure Area.  For additional information, please contact the Area
Directors or the WG Chairs.

ControLling mUltiple streams for tElepresence (clue)
-------------------------------------------
Current Status: Active Working Group

Chair(s):
  Paul Kyzivat 
  Mary Barnes 

Real-time Applications and Infrastructure Area Director(s):
  Gonzalo Camarillo 
  Robert Sparks 

Real-time Applications and Infrastructure Area Advisor:
  Gonzalo Camarillo 

Mailing Lists:
  Address:	clue@ietf.org
  To Subscribe:	https://www.ietf.org/mailman/listinfo/clue
  Archive:	http://www.ietf.org/mail-archive/web/clue/

Description of Working Group:

In the context of this WG, the term telepresence is used in a general
manner to describe systems that provide high definition, high quality
audio/video enabling a "being-there" experience.  One example is an
immersive telepresence system using specially designed and special
purpose rooms with multiple displays permitting life size image
reproduction using multiple cameras, encoders, decoders, microphones
and loudspeakers.

Current telepresence systems are based on open standards such as RTP,
SIP, H.264, the H.323 suite. However, they cannot easily interoperate
with each other without operator assistance and expensive additional
equipment which translates from one vendor to another. A major factor
limiting the interoperability of telepresence systems is the lack of a
standardized way to describe and negotiate the use of the multiple
streams of audio and video comprising the media flows.

The WG will create specifications for SIP-based conferencing systems
to enable communication of information about media streams so that a
sending system, receiving system, or intermediate system can make
reasonable decisions about transmitting, selecting, and rendering
media streams. This enables systems to make choices that optimize user
experience.

This working group is chartered to specify the following information
about media streams from one entity to another entity:

* Spatial relationships of cameras, displays, microphones, and
  loudspeakers - relative to each other and to likely positions of
  participants

* Viewpoint, field of view/capture for
  camera/microphone/display/loudspeaker - so that senders and
  intermediate devices can understand how best to compose streams for
  receivers, and the receiver will know the characteristics of its
  received streams

* Usage of the stream, for example whether the stream is presentation,
  or document camera output

* Aspect ratio of cameras and displays

* Which sources a receiver wants to receive.  For example, it might
  want the source for the left camera, or might want the source chosen
  by VAD (Voice Activity Detection)

Information between sources and sinks about media stream capabilities
will be exchanged.

The working group will define the semantics, syntax, and transport
mechanism for communicating the necessary information. It will
consider whether existing protocols for signaling, messaging and
transport are adequate or need to be extended. Any extensions to IETF
protocols will be done in appropriate WGs, for example extensions to
SDP in MMUSIC.

The scope of the work includes describing relatively static relations
between entities (participants and devices). It also includes handling
more dynamic relationships, such as specifying the audio and video
streams for defined speakers. Specifying the location of the current
speakers relative to display microphones needs to be provided
dynamically as speakers move.

As part of the receiver telling the sender what it wants dynamically,
explicit receiver notification to the sender of the desired video
stream and video pause will be considered.

The scope includes both systems that provide a fully immersive
experience, and systems that interwork with them and therefore need to
understand the same multiple stream semantics.

The focus of this work is on multiple RTP audio and video streams.
Other media types may be considered, however development of
methodologies for them is not within the scope of this work.

Interoperation with SIP and related standards for audio and video is
required.  However, backwards compatibility with existing
non-standards compliant telepresence systems is not required.

This working group is not currently chartered to work on issues of
continuous conference control including: far end camera control, floor
control, conference roster. The working group may identify
interoperability obstacles in existing open standards. If so, the WG
will develop requirements to be communicated to other IETF WGs or
Standards Forums, or recharter as appropriate.

Reuse of existing protocols and backwards compatibility with
SIP-compliant audio/video endpoints are important factors for the
working group to consider. The work will closely coordinate with the
appropriate areas (e.g., OPS and SEC), and working groups including
AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE.


Goals and Milestones:

Jul 2011 Submit informational draft to IESG on use cases
Jul 2011 Submit informational draft to IESG on framework and
         requirements
Nov 2011 Submit standards track specification(s) to IESG to support
         framework and requirements
_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue


From aallen@rim.com  Tue Jan 11 12:26:14 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8D7128C2C2 for ; Tue, 11 Jan 2011 12:26:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level: 
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5QSn6b60zL4 for ; Tue, 11 Jan 2011 12:26:14 -0800 (PST)
Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id A356128C113 for ; Tue, 11 Jan 2011 12:26:12 -0800 (PST)
X-AuditID: 0a401fcb-b7b20ae0000015d6-ee-4d2cbd6d46e3
Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs03ykf.rim.net (RIM Mail) with SMTP id BB.F2.05590.D6DBC2D4; Tue, 11 Jan 2011 15:28:29 -0500 (EST)
Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Jan 2011 15:28:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB1CE.15EEACD4"
x-cr-hashedpuzzle: AUx0 CEBB CThm CYy1 CqEv CvtR DBji Dn4r FHgB Fg2h FkTN F/yU Gn4g Hvh7 H9X8 IRPb; 1; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {6F96281A-7B78-48AF-A76D-52945CFD0B6C}; YQBhAGwAbABlAG4AQAByAGkAbQAuAGMAbwBtAA==; Tue, 11 Jan 2011 18:23:42 GMT; UgBlAHYAaQBzAGkAbwBuACAAbwBmACAAZAByAGEAZgB0AC0AYQBsAGwAZQBuAC0AZABpAHMAcABhAHQAYwBoAC0AaQBtAGUAaQAtAHUAcgBuAC0AYQBzAC0AaQBuAHMAdABhAG4AYwBlAGkAZAA=
x-cr-puzzleid: {6F96281A-7B78-48AF-A76D-52945CFD0B6C}
Content-class: urn:content-classes:message
Date: Tue, 11 Jan 2011 14:28:19 -0600
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Revision of draft-allen-dispatch-imei-urn-as-instanceid
Thread-Index: AcuxvK0D67rpeedSRYWnbAWNVi994Q==
From: "Andrew Allen" 
To: 
X-OriginalArrivalTime: 11 Jan 2011 20:28:29.0459 (UTC) FILETIME=[1B991E30:01CBB1CE]
X-Brightmail-Tracker: AAAAAgAAAZEXIZP1
Subject: [dispatch] Revision of draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jan 2011 20:26:15 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CBB1CE.15EEACD4
Content-Type: text/plain;
	charset="us-ascii"
content-transfer-encoding: quoted-printable

A revised version of draft-allen-dispatch-imei-urn-as-instanceid has
just been submitted.

 

It can be located at
http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-02.tx
t

 

This addresses all the editorial comments provided by Dale Worley. I
believe that this version now addresses all the comments received on the
list (provided by Dale and Paul Kyzivat).

 

Recently a revised version of draft-montemurro-gsma-imei-urn that is
referenced by the draft and addresses the comments on the BNF provided
by Dale Worley was also submitted.

 

It can be located at
http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-06.txt

 

 


---------------------------------------------------------------------=0A=
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.

------_=_NextPart_001_01CBB1CE.15EEACD4
Content-Type: text/html;
	charset="us-ascii"
content-transfer-encoding: quoted-printable
















A revised version of
draft-allen-dispatch-imei-urn-as-instanceid has just been submitted.



 



It can be located at http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-02=
.txt



 



This addresses all the editorial comments provided by D=
ale
Worley. I believe that this version now addresses all the comments received=
 on
the list (provided by Dale and Paul Kyzivat).



 



Recently a revised version of draft-montemurro-gsma-ime=
i-urn
that is referenced by the draft and addresses the comments on the BNF provid=
ed
by Dale Worley was also submitted.



 



It can be located at http:/=
/www.ietf.org/id/draft-montemurro-gsma-imei-urn-06.txt



 



 





--------------------------------------------------------------------- 
=
=0A=
This transmission (including any attachments) may contain confidential infor=
mation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information.=
 Any use of this information by anyone other than the intended recipient is=
 prohibited. If you have received this transmission in error, please immedia=
tely reply to the sender and delete this information from your system. Use,=
 dissemination, distribution, or reproduction of this transmission by uninte=
nded recipients is not authorized and may be unlawful.




------_=_NextPart_001_01CBB1CE.15EEACD4--

From pkyzivat@cisco.com  Tue Jan 11 13:09:06 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795213A635F for ; Tue, 11 Jan 2011 13:09:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.48
X-Spam-Level: 
X-Spam-Status: No, score=-110.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qijdzz5hYalR for ; Tue, 11 Jan 2011 13:09:05 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A1CC83A63CB for ; Tue, 11 Jan 2011 13:09:05 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigHALZWLE1AZnwM/2dsb2JhbACWKI4Rc6N4mFmFTASEZ4YlgyA
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Jan 2011 21:11:22 +0000
Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0BLBLGb010172 for ; Tue, 11 Jan 2011 21:11:22 GMT
Message-ID: <4D2CC779.2000503@cisco.com>
Date: Tue, 11 Jan 2011 16:11:21 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: dispatch@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] Revision of draft-allen-dispatch-imei-urn-as-instanceid
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Jan 2011 21:09:06 -0000

This looks ok to me.

	Thanks,
	Paul

On 1/11/2011 3:28 PM, Andrew Allen wrote:
> A revised version of draft-allen-dispatch-imei-urn-as-instanceid has
> just been submitted.
>
> It can be located at
> http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-02.txt
>
> This addresses all the editorial comments provided by Dale Worley. I
> believe that this version now addresses all the comments received on the
> list (provided by Dale and Paul Kyzivat).
>
> Recently a revised version of draft-montemurro-gsma-imei-urn that is
> referenced by the draft and addresses the comments on the BNF provided
> by Dale Worley was also submitted.
>
> It can be located at
> http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-06.txt
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From alex@vidyo.com  Wed Jan 12 04:47:29 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F8E3A6A95 for ; Wed, 12 Jan 2011 04:47:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xRJ+kYWpBZc for ; Wed, 12 Jan 2011 04:47:27 -0800 (PST)
Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 923203A6B1B for ; Wed, 12 Jan 2011 04:47:27 -0800 (PST)
Received: from st022.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id B324A78CCA3; Wed, 12 Jan 2011 07:49:46 -0500 (EST)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from mx1.myoutlookonline.com (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 1C4A878CC0D; Wed, 12 Jan 2011 07:49:46 -0500 (EST)
Received: from BH011.mail.lan ([10.110.21.111]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 12 Jan 2011 07:49:34 -0500
Received: from HUB011.mail.lan ([10.110.17.11]) by BH011.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Jan 2011 07:49:42 -0500
Received: from BE235.mail.lan ([10.110.32.235]) by HUB011.mail.lan ([10.110.17.11]) with mapi; Wed, 12 Jan 2011 07:49:38 -0500
From: Alex Eleftheriadis 
To: Harald Alvestrand 
Date: Wed, 12 Jan 2011 07:49:33 -0500
Thread-Topic: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
Thread-Index: AcuyVyk2y4oVoGXeTym5+s/EyONmdQ==
Message-ID: 
References: <4D25AD41.7060306@alvestrand.no>
In-Reply-To: <4D25AD41.7060306@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Jan 2011 12:49:42.0364 (UTC) FILETIME=[2E9581C0:01CBB257]
Cc: "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] Charter proposal: The activity hitherto known as	"RTC-WEB at IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jan 2011 12:47:29 -0000

I think this is an interesting and important activity, but I want to point =
out a few points of concern with the current proposal.

Although the charter indicates that there will be a "selection", it fails t=
o identify the criteria for this selection process. It is easy to see that =
this can lead to a shouting match. The only indication of a criterion for t=
he codecs is:

> * interoperate with compatible voice and video systems that are not web=20
> based


which, btw, you already re-interpreted to mean "brower-to-browser" in a lat=
er email.=20

I would therefore recommend that, if a single baseline codec is to be selec=
ted, the criteria are stated in the charter. If the criteria are to be defi=
ned later by the group, then that should be stated in the charter, with at =
least some indication of what the group wants to accomplish here.=20

Nit: Codecs are not protocols (cf. "The following protocols...").=20

Regards.=20

Alex

On Jan 6, 2011, at 1:53 PM, Harald Alvestrand wrote:

> This is the first of 3 messages going to the DISPATCH list (in the hope=20
> of keeping discussions somewhat organized).
>=20
> This is the draft of a charter for an IETF working group to consider the=
=20
> subject area of "Real time communication in the Web browser platform".=20
> This is one of a paired set of activities, the other one being a W3C=20
> activity (either within an existing WG or in a new WG) that defines APIs=
=20
> to this functionality.
>=20
> The two other messages will contain the W3C proposed charter and a=20
> kickoff for what's usually the most distracting topic in any such=20
> discussion: The name of the group.
> Without further ado:
>=20
> -------------------------------------
>=20
> Version: 2
>=20
> Possible Names:
> 
>=20
> Body:
>=20
> Many implementations have been made that use a Web browser to support=20
> interactive communications directly between users including voice,=20
> video, collaboration and gaming, but until now, such applications have=20
> required the installation of nonstandard plugins and browser extensions.=
=20
> There is a desire to standardize such functionality, so that this type=20
> of application can be run in any compatible browser.
>=20
> Traditionally, the W3C has defined API and markup languages such as HTML=
=20
> that work in conjunction with with the IETF over the wire protocols such=
=20
> as HTTP to allow web browsers to display media that does not have real=20
> time interactive constraints with another human.
>=20
> The W3C and IETF plan to collaborate together in their traditional way=20
> to meet the evolving needs of browsers. Specifically the IETF will=20
> provide a set of on the wire protocols, including RTP, to meet the needs=
=20
> on interactive communications, and the W3C will define the API and=20
> markup to allow web application developers to control the on the wire=20
> protocols. This will allow application developers  to write applications=
=20
> that run in a browser and facilitate interactive communications between=20
> users for voice and video communications, collaboration, and gaming.
>=20
> This working group will select and define a minimal set of protocols=20
> that will enable browsers to:
>=20
> * have interactive real time voice and video between users using RTP
> * interoperate with compatible voice and video systems that are not web=20
> based
> * support direct flows of non RTP application data between browsers for=20
> collaboration and gaming applications
>=20
> Fortunately very little development of new protocol at IETF is required=20
> for this, only selection of existing protocols and selection of minimum=20
> capabilities to ensure interoperability. The following protocols are=20
> candidates for including in the profile set:
>=20
> 1) RTP/ RTCP
>=20
> 2) a baseline audio codec for high quality interactive audio. Opus
> will be considered as one of the candidates
>=20
> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
> will be considered
>=20
> 4) a baseline video codec. H.264 and VP8 will be considered
>=20
> 5) Diffserv based QoS
>=20
> 6) NAT traversal using ICE
>=20
> 7) RFC 4833 based DTMF transport
>=20
> 8) RFC 4574 based Label support for identifying streams purpose
>=20
> 9) Secure RTP and keying
>=20
> 10) support for IPv4, IPv6 and dual stack browsers
>=20
> The working group will cooperate closely with the W3C activity that=20
> specifies a semantic level API that allows the control and manipulation=20
> of all the functionality above. In addition, the API needs to=20
> communicate state information and events about what is happening in the=20
> browser that to applications running in the browser. These events and=20
> state need to include information such as: receiving RFC 4833 DTMF, RTP=20
> and RTCP statistics, state of DTLS/SRTP,  and signalling state.
>=20
> The following topics will be out of scope for the initial phase of the=20
> WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST,=20
> Geolocation, IM & Presence, NSIS, Resource Priority,
>=20
> Milestones:
>=20
> February 2011 Candidate "sample" documents circulated to DISPATCH
>=20
> March 2011 BOF at IETF Prague
>=20
> April 2011 WG charter approved by IESG. Chosen document sets adopted as=20
> WG documents
>=20
> May 2011 Functionality to include and main alternative protocols identifi=
ed
>=20
> July 2011 IETF meeting
>=20
> Aug 2011 Draft with text reflecting agreement of what the protocol set=20
> should be
>=20
> Nov 2010 Documentation specifying mapping of protocol functionality to=20
> W3C-specified API produced
>=20
> Dec 2011 Protocol set specification to IESG
>=20
> April 2012 API mapping document to IESG
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From peter.musgrave@magorcorp.com  Wed Jan 12 05:36:11 2011
Return-Path: 
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D94F28C107 for ; Wed, 12 Jan 2011 05:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWA26wK0M9py for ; Wed, 12 Jan 2011 05:36:10 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id CA67D3A6B2C for ; Wed, 12 Jan 2011 05:36:09 -0800 (PST)
Received: by vws7 with SMTP id 7so113547vws.31 for ; Wed, 12 Jan 2011 05:38:28 -0800 (PST)
Received: by 10.220.191.76 with SMTP id dl12mr288446vcb.66.1294839506746; Wed, 12 Jan 2011 05:38:26 -0800 (PST)
Received: from [172.16.1.14] ([12.139.174.194]) by mx.google.com with ESMTPS id ft27sm261694vbb.8.2011.01.12.05.38.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Jan 2011 05:38:25 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Peter Musgrave 
In-Reply-To: 
Date: Wed, 12 Jan 2011 05:38:22 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <27D7CE2F-E08E-47A2-B73F-15FAFD5CBC6C@magorcorp.com>
References: <4D25AD41.7060306@alvestrand.no> 
To: Alex Eleftheriadis 
X-Mailer: Apple Mail (2.1082)
Cc: Harald Alvestrand , "rtc-web@alvestrand.no" , "dispatch@ietf.org" 
Subject: Re: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Jan 2011 13:36:11 -0000

Hi,=20

I also think this is very useful work.=20

I would really like have IETF side step the video codec choice vortex. =
There has been a long and impassioned CODEC dialog wrt the