Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

Hadriel Kaplan <HKaplan@acmepacket.com> Sun, 11 September 2011 12:58 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3970421F8669 for <rtcweb@ietfa.amsl.com>; Sun, 11 Sep 2011 05:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.502
X-Spam-Level:
X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPnEweZHSxaa for <rtcweb@ietfa.amsl.com>; Sun, 11 Sep 2011 05:58:06 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id A003321F863E for <rtcweb@ietf.org>; Sun, 11 Sep 2011 05:58:06 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 11 Sep 2011 08:59:53 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 11 Sep 2011 08:59:52 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]
Thread-Index: AQHMcIKwV9u+0Arv+EmqYITZjPuIBw==
Date: Sun, 11 Sep 2011 12:59:50 +0000
Message-ID: <1C177DD3-C9AC-49D3-BDD6-0FC43CB9F26F@acmepacket.com>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <E4EC1B17-0CC4-4F79-96DD-84E589FCC4F0@edvina.net> <4E67C3F7.7020304@jesup.org> <BE60FA11-8FFF-48E5-9F83-4D84A7FBE2BE@vidyo.com> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <C3759687E4991243A1A0BD44EAC8230339CA68F054@BE235.mail.lan> <CAOJ7v-2u0UuNXh7bzmZFwiSucbsh=Ps=C3ZM5M3cJrXRmZgODA@mail.gmail.com> <CAKhHsXHXCkNdjtpxCSCk+ABbtxY15GEgouE6X6-sn-LqhnidQw@mail.gmail.com> <4E6A56D4.2030602@skype.net> <CABcZeBOdP6cAqBoiSV-Vdv1_EK3DfgnMamT3t3ccjDOMfELfBw@mail.gmail.com> <CAKhHsXFdU1ZaKQF8hbsOxwTS-_RfmFqQhgzGe=K4mRp+wz+_nQ@mail.gmail.com> <4E6A81EC.3080002@jesup.org> <4E6AE22A.2070106@alum.mit.edu>
In-Reply-To: <4E6AE22A.2070106@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D7DF767EC5EBF14A81FBC8BC7AEE0751@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Sep 2011 12:58:07 -0000

I doubt you'd get MMUSIC to change their tune. (pun intended)
They don't seem to accept lack of adoption as an indication that we need an alternative for things.  For example, mandating ICE for IPv4/v6 dual-stack offers.

-hadriel

On Sep 10, 2011, at 12:06 AM, Paul Kyzivat wrote:

> The "right" solution is to go back to mmusic for an O/A mechanism for secure/insecure media that is more usable than capneg. If its deemed that doing this would take too long, and its necessary to do something special for rtcweb, then a parallel effort ought to be started to sort out how it can interoperate with SIP or anything else that uses O/A.
> 
> (The "good" news is that I doubt there are many (any?) deployed uses of capneg in SIP for negotiation of secure/insecure media.)
> 
> 	Thanks,
> 	Paul
>