From fluffy@cisco.com Sat Mar 2 15:33:33 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8F421F85A4 for ; Sat, 2 Mar 2013 15:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.584 X-Spam-Level: X-Spam-Status: No, score=-110.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBsn3B0X+l5A for ; Sat, 2 Mar 2013 15:33:33 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D80E021F855F for ; Sat, 2 Mar 2013 15:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6667; q=dns/txt; s=iport; t=1362267213; x=1363476813; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tfX4WemKA/wWwD6XuQ+3EvRIPtiJaZUSd6/pcCa81Ec=; b=aTcFdP35P4sdVD5hs9m0HhVJ9YeZ25uGdjKLI3S16iARxsAowbqNwrRx Ej4M+DncN/dJ2RIQ6pMMod1B0QpWrS4IZndefJDsEeBqQEfQeKRnLML1s IT8t+032j6vIkal7VgPhAEOXA/rcXV22jQXWWx/PRE8AQz+p7dYU9GRpH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFOLMlGtJV2b/2dsb2JhbABFDsJAfBZzgh8BAQEDAQEBAWsLBQsCAQgOCgodBycLFBECBA4FCAGIBAYMwTmNV4ETAjEHgl9hA4g2jy6PToFSdz+Baj0 X-IronPort-AV: E=Sophos;i="4.84,769,1355097600"; d="scan'208";a="183058332" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 02 Mar 2013 23:33:32 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r22NXWip006435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Mar 2013 23:33:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Sat, 2 Mar 2013 17:33:31 -0600 From: "Cullen Jennings (fluffy)" To: Paul Kyzivat Thread-Topic: [dispatch] Remapping existing protocols for web usage: websockets or data channels? Thread-Index: AQHOF55ZXAjKFeWmzUuAYGSootqxHw== Date: Sat, 2 Mar 2013 23:33:31 +0000 Message-ID: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> , <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> In-Reply-To: <512A8982.3080809@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.9.122] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <27C36816BE4D2745B347BEFFDF0117B4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , "stephane.cazeaux@orange.com" Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 23:33:34 -0000 Part of my hope was that if all these things were on the BFCP list, we cou= ld come to some sanity about what the optimal number of options are. On Feb 24, 2013, at 3:43 PM, Paul Kyzivat wrote: > On 2/24/13 5:28 PM, stephane.cazeaux@orange.com wrote: >> That was my understanding. My point is that on the browser, the data >> channel is part of the webrtc stuff. While websocket is to me more >> suitable for such browser to server exchange. >> Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE >> endpoint since, unless I am wrong, a CLUE endpoint will also have to >> support bfcp over tcp (or udp) to interwork with legacy ? >=20 > First, AFAIK there are currently no plans to put bfcp over a data channel= , but I think there should be. >=20 > My reason is because that is a mechanism that could be supported by a an = RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint may = still need to support bfcp over tcp or udp for legacy interworking. >=20 > It would also be possible for an RTCWEB clue client to use bfcp over a we= bsocket. >=20 > The question is: how many of these alternatives do we want to define and = then ask people to support in their products. The more alternatives we have= the less likely we are to get interoperability. >=20 > We have now started down the path of remapping existing protocols (first = SIP, then MSRP, now maybe BFCP) over websockets. Meanwhile RTCWEB is defini= ng data channels over SCTP and and CLUE is tentatively planning to put its = protocol over that. So maybe we had better have a discussion of where we ar= e trying to go, and if what we are doing will get us to a good place. >=20 > Thanks, > Paul >=20 >> St=E9phane. >> ------------------------------------------------------------------------ >> De : Paul Kyzivat >> Envoy=E9 : 24/02/2013 02:32 >> =C0 : CAZEAUX Stephane OLNC/OLPS >> Cc : dispatch@ietf.org >> Objet : Re: [dispatch] FW: New Version Notification for >> draft-pascual-dispatch-bfcp-websocket-00.txt >>=20 >> On 2/22/13 11:40 AM, stephane.cazeaux@orange.com wrote: >>> Hi Paul, >>>=20 >>> Having BFCP over data channel would limit the applicability of BFCP to = webrtc (other formulation: it would require the webrtc framework to get BFC= P in the browser), while we might want to have BFCP protocol in web client = outside of webrtc. >>=20 >> I guess I didn't explain myself well enough. >>=20 >> What I am suggesting is bfcp over the DTLS/SCTP stack that is being used >> for RTCWEB data channels, and that the mechanisms used to negotiate the >> stream numbers for each direction be compatible with RTCWEB. In this way >> a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.g. >> C-based) implementation is also possible. >>=20 >> This is the same direction we are investigating for the clue data channe= l. >>=20 >> The term "data channel" here is perhaps overloaded, because it could >> mean a real RTCWEB data channel, or something similar for other >> environments. Ideally we would just use SCTP terms, but it has no term >> for a bidirectional "channel", only unidirectional streams. But this >> should end up being formalized in the SDP. >>=20 >> Thanks, >> Paul >>=20 >>> St=E9phane. >>>=20 >>> -----Message d'origine----- >>> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Envoy=E9 : jeudi 21 f=E9vrier 2013 22:32 >>> =C0 : dispatch@ietf.org >>> Objet : Re: [dispatch] FW: New Version Notification for draft-pascual-d= ispatch-bfcp-websocket-00.txt >>>=20 >>> Victor, >>>=20 >>> A question for you: >>>=20 >>> Another possibility is to map bfcp over a data channel as being specifi= ed for rtcweb. >>>=20 >>> If that were done, would it be a suitable alternative to bfcp over webs= ocket? >>>=20 >>> We are also going to need bfcp support in conjunction with CLUE. >>> And CLUE is going to have its own data channel. We are aiming to use an= rtcweb-compatible data channel so that we can have rtcweb browser based cl= ue clients. >>>=20 >>> If bfcp also worked over a data channel, then these multiple uses of da= ta channels could all coexist on a single SCTP association. And they could = work the same regardless of whether or not there are web clients. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 2/21/13 12:38 PM, Victor Pascual Avila wrote: >>>> Hi all, >>>>=20 >>>> We have submitted a new Internet draft to describe the WebSocket >>>> Protocol as a Transport for the Binary Floor Control Protocol (BFCP). >>>> We are looking forward to your review comments. >>>>=20 >>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>>>=20 >>>> Best regards, >>>> -Victor >>>>=20 >>>>=20 >>>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" >>>> >>>> wrote: >>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt >>>>> has been successfully submitted by Victor Pascual and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Filename: draft-pascual-dispatch-bfcp-websocket >>>>> Revision: 00 >>>>> Title: The WebSocket Protocol as a Transport for the Binary = Floor >>>>> Control Protocol (BFCP) >>>>> Creation date: 2013-02-15 >>>>> Group: Individual Submission >>>>> Number of pages: 9 >>>>> URL: >>>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-webso >>>>> cket- >>>>> 00.txt >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>>>>=20 >>>>>=20 >>>>> Abstract: >>>>> The WebSocket protocol enables two-way realtime communication betw= een >>>>> clients and servers. This document specifies a new WebSocket sub- >>>>> protocol as a reliable transport mechanism between Binary Floor >>>>> Control Protocol (BFCP) entities to enable usage of BFCP in new >>>>> scenarios. This document normatively updates >>>>> [I-D.draft-ietf-bfcpbis-rfc4582bis] and >>>>> [I-D.draft-ietf-bfcpbis-rfc4583bis] >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Sat Mar 2 15:33:34 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902A321F85A4 for ; Sat, 2 Mar 2013 15:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.585 X-Spam-Level: X-Spam-Status: No, score=-110.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfZiYplmHLTX for ; Sat, 2 Mar 2013 15:33:33 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A424B21F8585 for ; Sat, 2 Mar 2013 15:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2202; q=dns/txt; s=iport; t=1362267213; x=1363476813; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=izFyn9UJON/wEZ84Ix92zistQSC+WBt98/gtn5FtSV8=; b=YYUJHsh+w7zCHakJOpLmZgVcsoGcVY+cO3/mj534MK+NE9adB0zyp6YK oZJj8p0suqPTZCoovkZgvnA7KcLuK8j/D9m5yNQmLNxmRHY2NaUY8pZ9m i9c2CfciuCbVStszNRfgbzFEViJnm0prMiGWkuBir+kuWYXZEMV4JvIur Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFOLMlGtJV2a/2dsb2JhbAA8CcJOfBZzgiABAQQBAQE3NAsQAgEIIhQQJwslAgQOBQiICwzBOY1TgRcCMQeCX2EDgUiWHI9OgwiCJw X-IronPort-AV: E=Sophos;i="4.84,769,1355097600"; d="scan'208";a="183087814" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 02 Mar 2013 23:33:33 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r22NXXoh029744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Mar 2013 23:33:33 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sat, 2 Mar 2013 17:33:32 -0600 From: "Cullen Jennings (fluffy)" To: Peter Saint-Andre Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity Thread-Index: AQHOF55ZJhdVcbJHkUyhphnvwmWC1A== Date: Sat, 2 Mar 2013 23:33:31 +0000 Message-ID: References: <51102D21.10503@stpeter.im> In-Reply-To: <51102D21.10503@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.9.122] Content-Type: text/plain; charset="us-ascii" Content-ID: <1BA1AA0646CC2042BC1478D97BADD5EF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 23:33:34 -0000 I'd be fascinated to hear the need for this - PAI is such a disaster zone t= hat I'd want to make sure the envisioned usage did not run into the many la= nd mines around PAI. It might be that some other header might meet the need= s better than PAI.=20 Cullen - co-authors of the ill fated RFC 3325=20 PS - you might want consider the "Call-Info" header - it would be very cool= to the have HTTP URL in that pointed at the JSON vCard for the user.=20 See http://tools.ietf.org/html/rfc3261#section-20.9 On Feb 4, 2013, at 3:50 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Dear DISPATCHers, >=20 > At the XMPP Summit last week, for various reasons that aren't > particularly relevant here, we talked a bit about how to include an > XMPP address in the header of a SIP message. Folks at the meeting > concluded that the P-Asserted-Identity header would work quite well > (certainly better than a second Contact header). Unfortunately, RFC > 3225 defines the P-Asserted-Identity as follows: >=20 > A P-Asserted-Identity header field value MUST consist of exactly one > name-addr or addr-spec. There may be one or two P-Asserted-Identity > values. If there is one value, it MUST be a sip, sips, or tel URI. > If there are two values, one value MUST be a sip or sips URI and the > other MUST be a tel URI. >=20 > It's not clear to me why the definition restricts the scheme to sip, > sips, or tel. Could someone provide some insight about that? Would > things break if we allowed more URI schemes there, in particular the > xmpp scheme? >=20 > Thanks! >=20 > Peter >=20 > - --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg > 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/ > =3Dlu3v > -----END PGP SIGNATURE----- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Sat Mar 2 15:33:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE1921F85CC for ; Sat, 2 Mar 2013 15:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.585 X-Spam-Level: X-Spam-Status: No, score=-110.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1vAe9wUemlu for ; Sat, 2 Mar 2013 15:33:41 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 92F8D21F855F for ; Sat, 2 Mar 2013 15:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=167; q=dns/txt; s=iport; t=1362267221; x=1363476821; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MzrKT6mye75zbqcEuTjKkRDTSxQJAmoDVzLSP7UZ37A=; b=T+PyPwbjBXvCy6Y6fzbUy27cwnJixD4r4bpIBOadB+js9PlAtTmLb5St Gqgplt6reNWdwK79HV7NfxMFzVZAr7alkAFx9NGTRKvpxk4upty6S1TIt Kq0yE5B2AvJkejWgaBwLkW+MqL7ioEwSot+8lGOAQMvR6ES8ZRExFKjPf U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAGeKMlGtJXG9/2dsb2JhbABFhgm8RXwWc4IfAQEBAwE6PwULAgEIIhQQMiUCBA4FCIgFBsFHjmwxB4JfYQOnMoMIgic X-IronPort-AV: E=Sophos;i="4.84,769,1355097600"; d="scan'208";a="183054612" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 02 Mar 2013 23:33:40 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r22NXdSI003858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Mar 2013 23:33:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Sat, 2 Mar 2013 17:33:33 -0600 From: "Cullen Jennings (fluffy)" To: "Dale R. Worley" Thread-Topic: [dispatch] TeRQ use cases Thread-Index: AQHOF55ZH54ZZ7g6SUS74vaEUbe2Dw== Date: Sat, 2 Mar 2013 23:33:32 +0000 Message-ID: References: <55A5A9A87506CB4BA580BF9D531957DA921A03FA@STNTEXCH01.cis.neustar.com> <201302042052.r14Kqu3E1205998@shell01.TheWorld.com> In-Reply-To: <201302042052.r14Kqu3E1205998@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.9.122] Content-Type: text/plain; charset="us-ascii" Content-ID: <68409C15F0B6F2459A11B69F2C08B740@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] TeRQ use cases X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 23:33:42 -0000 On Feb 4, 2013, at 2:52 PM, Dale R. Worley wrote: > That loods like a very good start on enunciating the problems to be > addressed. +1 From fluffy@cisco.com Sat Mar 2 15:33:46 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DF621F85D2 for ; Sat, 2 Mar 2013 15:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.353 X-Spam-Level: X-Spam-Status: No, score=-110.353 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHKh8wvTNICK for ; Sat, 2 Mar 2013 15:33:45 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 93A6921F85C0 for ; Sat, 2 Mar 2013 15:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1036; q=dns/txt; s=iport; t=1362267225; x=1363476825; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CAlmJSVjJ7yY+kFDNg0spZeuDNfU9hc88oiE4VOh+FE=; b=RByFf/VA3Mr4W03aEAaG2yE9L3KsYBmT0cBuytblxAMm+JujI2Gro8sq EYb35ggmSE1OfqJYDrvICEbXwzOug3XjIqVKn+LkHtBp8turozMO+OwA3 XRQcw9e1uZqN0SymTefvcFMCGEWbSfun7x/t7q4iu+LRbtpXTyuusxRYC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFOLMlGtJXHA/2dsb2JhbABFwk58FnOCHwEBAQMBeQULAgEIGAoZCyERJQIEDgUIh3kDCQa4CA2JMIxFfIEpAjEHgl9hA4g2jDGNM4UYgVKBNoIn X-IronPort-AV: E=Sophos;i="4.84,769,1355097600"; d="scan'208";a="183058342" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 02 Mar 2013 23:33:45 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r22NXjQx016647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Mar 2013 23:33:45 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Sat, 2 Mar 2013 17:33:44 -0600 From: "Cullen Jennings (fluffy)" To: Tom Taylor Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQHOF55gZsO7JlpDm0qqNyLpD8iX+g== Date: Sat, 2 Mar 2013 23:33:43 +0000 Message-ID: References: <50ABBAD6.9050103@gmail.com> <50FB6569.8020008@gmail.com> In-Reply-To: <50FB6569.8020008@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.9.122] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2BC089748A6EB44D8D5AD076677C4826@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 23:33:46 -0000 Tom, my apologies for mis quoting you like this.=20 On Jan 19, 2013, at 9:32 PM, Tom Taylor wrote: > Those weren't my remarks. All I did on Nov. 20 was forward Andrew's note = in readable form. >=20 > On 19/01/2013 11:49 AM, Cullen Jennings (fluffy) wrote: >>=20 >> On Nov 20, 2012, at 10:16 AM, Tom Taylor >> wrote: >>=20 >>> Those that think privacy issues are insufficiently addressed need >>> to explain why the IMEI is of significantly greater concern in >>> terms of revealing privacy than the UUID when used as an instance >>> ID. >>=20 >> That has been explained in detail multiple times. For one thing, the >> user can't change the IMEI. For a second thing, it can be directly >> mapped to a specific user in many cases. >>=20 >>>=20 >>> In our view the security concerns raised have now been sufficiently >>> addressed in the drafts and to a much higher bar than that of UUID >>> in RFC 5626. >>=20 >> I strongly disagree. >>=20 >>=20 From fluffy@cisco.com Sat Mar 2 15:33:47 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4629A21F85D7 for ; Sat, 2 Mar 2013 15:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.363 X-Spam-Level: X-Spam-Status: No, score=-110.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NVteC3tJIfh for ; Sat, 2 Mar 2013 15:33:46 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5425521F85C0 for ; Sat, 2 Mar 2013 15:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4983; q=dns/txt; s=iport; t=1362267226; x=1363476826; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5cBageUlai6rfIqs8ZRy1zycEmRmCGo1Wd+A3DbiFdg=; b=cRePzgLYM6goy0COB7AfpYH6epDGjUFzTKwto3TIsTw75iC7DObVxibg v1Cjr4EbEhLc16zCdbJyjp5Ab6NtGUiNKEpbsfNRaa0Eyb6pPSgjnob5p r/ymIbQxBQv/0wH5Yw0hxslhJ8lNJlJk39/RBLKfVr+4QwbqUh8SAx5NH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJWLMlGtJXG//2dsb2JhbAA8CcJOfBZzgh8BAQEDAQEBATc0CwULAgEIDgMEAQEBChQFBAchBgsUCQgCBA4FCId5AwkGDLd8DYksBIxFfBIKgQ0CJgsHgl9hA5RnjTOFGIFSgTaCJw X-IronPort-AV: E=Sophos;i="4.84,769,1355097600"; d="scan'208";a="180063803" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 02 Mar 2013 23:33:45 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r22NXjtG017308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Mar 2013 23:33:45 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Sat, 2 Mar 2013 17:33:44 -0600 From: "Cullen Jennings (fluffy)" To: Andrew Allen Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQHOF55gZsO7JlpDm0qqNyLpD8iX+g== Date: Sat, 2 Mar 2013 23:33:43 +0000 Message-ID: References: <50ABBAD6.9050103@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.9.122] Content-Type: text/plain; charset="us-ascii" Content-ID: <1FD0C9C939B6664E8D98E050CA9C5D77@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 23:33:47 -0000 But the instance ID is in a register sent to trusted providers that know th= e users name, credentials etc and can be send in an encrypted channel. This= is a bit different it that it goes to other users. The analysis is not at = the same.=20 On Jan 19, 2013, at 11:31 AM, Andrew Allen wrote: > Cullen >=20 > To clarify these comments I think are your comments not Tom Taylor's (Tom= simply forwarded my original post as it was rejected due to attached diff = files). >=20 > Where does it state in RFC 5626 or anywhere else that an instance ID can = be changed by the user? >=20 > In fact RFC 5626 states the opposite: >=20 > 3.1. Summary of Mechanism > Each UA has a unique instance-id that stays the same for this UA even = if the UA reboots or is power cycled. =20 >=20 > And >=20 > 4.1. Instance ID Creation >=20 > Each UA MUST have an Instance Identifier Uniform Resource Name (URN) [= RFC2141] that uniquely identifies the device. Usage of a URN > provides a persistent and unique name for the UA instance. It also pr= ovides an easy way to guarantee uniqueness within the AOR. This > URN MUST be persistent across power cycles of the device. =20 >=20 > So the instance ID is persistent (RFC 5626 wording) and does not change a= nd is not changeable by the user. Whether the instance ID is a UUID or IMEI= this does not change. >=20 > If an Instance ID containing a UUID is provided in a SIP request or respo= nse to another party then it can be stored as the instance ID of a device b= elonging to that user if their identity is known. Then if the same instance= ID is provided again in a SIP request when the originating user requests a= nonymity then that user can potentially be identified by correlation with t= he stored instance ID. =20 >=20 > If I call you and your device rings and in the response I receive the ins= tance ID I can potentially learn the Instance ID of the specific device eve= n if it is a UUID. >=20 > This is the same regardless of whether the instance ID is a UUID or IMEI.= In 3GPP usage the instance ID is never supplied to the far end party excep= t for the case of emergency calls where the far end is a PSAP. >=20 > RFC 5626 does not seem overly concerned about this privacy issue as it ha= s a very weak statement - prefer to omit is a far lower strength than MUST = NOT or SHOULD NOT. >=20 > The only thing it states about it is: >=20 > 4.1. Instance ID Creation >=20 > One case where a UA could prefer to omit the "sip.instance" media featu= re tag is when it is making an anonymous request or some other privacy con= cern=20 > requires that the UA not reveal its identity. >=20 > 3GPP procedures and draft-allen-dispatch-imei-urn-as-instanceid protect r= evelation of the Instance ID far more than is required by RFC 5626. >=20 > Andrew >=20 > -----Original Messsage----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf Of Cullen Jennings (fluffy) > Sent: Saturday, January 19, 2013 11:49 AM > To: Tom Taylor; Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn an= d, draft-allen-dispatch-imei-urn-as-instanceid submitted >=20 >=20 > On Nov 20, 2012, at 10:16 AM, Tom Taylor wrot= e: >=20 >> Those that think privacy issues are insufficiently addressed need to exp= lain why the IMEI is of significantly greater concern in terms of revealing= privacy than the UUID when used as an instance ID. >=20 > That has been explained in detail multiple times. For one thing, the user= can't change the IMEI. For a second thing, it can be directly mapped to a = specific user in many cases.=20 >=20 >>=20 >> In our view the security concerns raised have now been sufficiently addr= essed in the drafts and to a much higher bar than that of UUID in RFC 5626. >=20 > I strongly disagree. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately 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 fluffy@cisco.com Sat Mar 2 15:33:48 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3148F21F85D9 for ; Sat, 2 Mar 2013 15:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.586 X-Spam-Level: X-Spam-Status: No, score=-110.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hORqOgQAO9JN for ; Sat, 2 Mar 2013 15:33:47 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 278B621F85D4 for ; Sat, 2 Mar 2013 15:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4986; q=dns/txt; s=iport; t=1362267227; x=1363476827; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=d/hS6SKlwA0auIx1fN5tCyfjB5oLpDMPh2XCHx9jm9s=; b=MDkal/TIjeoEUl0NatIe/bt56UiRn6CDKOCVzUoMg7dxuXCKWqVTSS5e prv1uEWtPHmZ+URG6bY7b9wkdQhDPK+hXWJlyCFm17p8BTrm3Oi6JzYcw ozyFtFr7WRbQeuElkRL9S8IOOJh+nigqhz1X0p6i/2+Gb3j7DYyAInykc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFOLMlGtJV2b/2dsb2JhbAA8CcJOfBZzgh8BAQEDAQEBATc0CwULAgEIDgMEAQEBChQFBAchBgsUCQgCBA4FCId5AwkGDLd8DYksBIxFfBIKgQ0CJgsHgl9hA5RnjTOFGIFSgTaCJw X-IronPort-AV: E=Sophos;i="4.84,769,1355097600"; d="scan'208";a="183087825" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 02 Mar 2013 23:33:46 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r22NXkrm006620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Mar 2013 23:33:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Sat, 2 Mar 2013 17:33:34 -0600 From: "Cullen Jennings (fluffy)" To: Andrew Allen Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQHOF55aZsO7JlpDm0qqNyLpD8iX+g== Date: Sat, 2 Mar 2013 23:33:33 +0000 Message-ID: References: <50ABBAD6.9050103@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.9.122] Content-Type: text/plain; charset="us-ascii" Content-ID: <6AA270F0851E8F4CA0125E62BDD2A030@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 23:33:48 -0000 But the instance ID is in a register sent to trusted providers that know th= e users name, credentials etc and can be send in an encrypted channel. This= is a bit different it that it goes to other users. The analysis is not at = the same.=20 On Jan 19, 2013, at 11:31 AM, Andrew Allen wrote: > Cullen >=20 > To clarify these comments I think are your comments not Tom Taylor's (Tom= simply forwarded my original post as it was rejected due to attached diff = files). >=20 > Where does it state in RFC 5626 or anywhere else that an instance ID can = be changed by the user? >=20 > In fact RFC 5626 states the opposite: >=20 > 3.1. Summary of Mechanism > Each UA has a unique instance-id that stays the same for this UA even= if the UA reboots or is power cycled. =20 >=20 > And >=20 > 4.1. Instance ID Creation >=20 > Each UA MUST have an Instance Identifier Uniform Resource Name (URN) = [RFC2141] that uniquely identifies the device. Usage of a URN > provides a persistent and unique name for the UA instance. It also pr= ovides an easy way to guarantee uniqueness within the AOR. This > URN MUST be persistent across power cycles of the device. =20 >=20 > So the instance ID is persistent (RFC 5626 wording) and does not change a= nd is not changeable by the user. Whether the instance ID is a UUID or IMEI= this does not change. >=20 > If an Instance ID containing a UUID is provided in a SIP request or respo= nse to another party then it can be stored as the instance ID of a device b= elonging to that user if their identity is known. Then if the same instance= ID is provided again in a SIP request when the originating user requests a= nonymity then that user can potentially be identified by correlation with t= he stored instance ID. =20 >=20 > If I call you and your device rings and in the response I receive the ins= tance ID I can potentially learn the Instance ID of the specific device eve= n if it is a UUID. >=20 > This is the same regardless of whether the instance ID is a UUID or IMEI.= In 3GPP usage the instance ID is never supplied to the far end party excep= t for the case of emergency calls where the far end is a PSAP. >=20 > RFC 5626 does not seem overly concerned about this privacy issue as it ha= s a very weak statement - prefer to omit is a far lower strength than MUST = NOT or SHOULD NOT. >=20 > The only thing it states about it is: >=20 > 4.1. Instance ID Creation >=20 > One case where a UA could prefer to omit the "sip.instance" media featu= re tag is when it is making an anonymous request or some other privacy con= cern=20 > requires that the UA not reveal its identity. >=20 > 3GPP procedures and draft-allen-dispatch-imei-urn-as-instanceid protect r= evelation of the Instance ID far more than is required by RFC 5626. >=20 > Andrew >=20 > -----Original Messsage----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf Of Cullen Jennings (fluffy) > Sent: Saturday, January 19, 2013 11:49 AM > To: Tom Taylor; Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn an= d, draft-allen-dispatch-imei-urn-as-instanceid submitted >=20 >=20 > On Nov 20, 2012, at 10:16 AM, Tom Taylor wrot= e: >=20 >> Those that think privacy issues are insufficiently addressed need to exp= lain why the IMEI is of significantly greater concern in terms of revealing= privacy than the UUID when used as an instance ID. >=20 > That has been explained in detail multiple times. For one thing, the user= can't change the IMEI. For a second thing, it can be directly mapped to a = specific user in many cases.=20 >=20 >>=20 >> In our view the security concerns raised have now been sufficiently addr= essed in the drafts and to a much higher bar than that of UUID in RFC 5626. >=20 > I strongly disagree. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately 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 stpeter@stpeter.im Sat Mar 2 18:36:24 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECD421F85FD for ; Sat, 2 Mar 2013 18:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xre66MWSHVu5 for ; Sat, 2 Mar 2013 18:36:23 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ADC9821F85E7 for ; Sat, 2 Mar 2013 18:36:23 -0800 (PST) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2019B406A8; Sat, 2 Mar 2013 19:44:25 -0700 (MST) Message-ID: <5132B72B.70205@stpeter.im> Date: Sat, 02 Mar 2013 19:36:27 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <51102D21.10503@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 02:36:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/2/13 4:33 PM, Cullen Jennings (fluffy) wrote: > > I'd be fascinated to hear the need for this - PAI is such a > disaster zone that I'd want to make sure the envisioned usage did > not run into the many land mines around PAI. It might be that some > other header might meet the needs better than PAI. We don't *need* PAI, but we'd like some way to indicate over SIP the XMPP address of a dual-stack user agent. > PS - you might want consider the "Call-Info" header - it would be > very cool to the have HTTP URL in that pointed at the JSON vCard > for the user. > > See http://tools.ietf.org/html/rfc3261#section-20.9 That looks like just the ticket, thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRMrcqAAoJEOoGpJErxa2p7fUP/3LxagjXNySkHq8VQWXPxy3r FLFq3r034V2X29uDHk25xqfoxZ/NvnXX/Xdr4r8VOHa+uUIHG6D3DWFQdLb/FkkA 1eGDauaB1eU2TZpdWGaZ7BjOv4nzcwnMnfx3wLUMFSBQDzsSLTEJ1cSx6dCBv36B l7JtGzzHb8p6rvMh1fGTSVJ9fFPwtNQyYlegcG7pRR5KfCYYgq7e+eXJCyYAcyQk OIbYOnwKUQmzVgeUtUFXHuHzjx6YpCcZZuGkG29t/fhh+AfrNgSdYf+ngurjIwFH BGh6vjvs2aP+dDagdiVh7nZ/H2k1vHnNjSbYHNelK9OVUFryL5lwHYRzf1vSxNUy qeDpXZaIzAepugnJ4XDhm0Sy3D5lNG45ZK0Adrk6DHRw7lWfPjlaORwsB5nTE7We w2lECvp3Bb16Ijrj5z90cXQq7v0bIYkJom2aaZpztIxftBaR+Nz2kcvVpYV0OU0Q 81RwB7eoawFkSYzuCAEUOZ6ZpK5pNy4euLFI5hpm/U5HvslnMr9AK4KpeBqwstTb CzgkUeVX/bSTC8c0D87lLS2U3GpY+sb6IY7XZN25ZnDmBpvqVd3osJe4wZohyNyS 0M3R9+fL/icGZIrYz5nCzn7CE9xQJJ6Xc5TemQn+G8W92IQqXSdbJTWG4JjO1ANg I/RWYpK6q/D7Ch5A4j+E =8OqW -----END PGP SIGNATURE----- From keith.drage@alcatel-lucent.com Sun Mar 3 03:33:14 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F29621F8698 for ; Sun, 3 Mar 2013 03:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.359 X-Spam-Level: X-Spam-Status: No, score=-109.359 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWwoOoh4dAif for ; Sun, 3 Mar 2013 03:33:13 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5C121F86A5 for ; Sun, 3 Mar 2013 03:33:06 -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 r23BWxR2001335 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 3 Mar 2013 12:33:00 +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; Sun, 3 Mar 2013 12:32:59 +0100 From: "DRAGE, Keith (Keith)" To: "Cullen Jennings (fluffy)" , Paul Kyzivat Date: Sun, 3 Mar 2013 12:32:57 +0100 Thread-Topic: [dispatch] Remapping existing protocols for web usage: websockets or data channels? Thread-Index: AQHOF55ZXAjKFeWmzUuAYGSootqxH5iT1PBg Message-ID: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> , <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> 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-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "dispatch@ietf.org" , "stephane.cazeaux@orange.com" Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 11:33:14 -0000 At the moment these things are out of scope of BFCPBIS as the charter as cu= rrently worded would prevent this. But I agree that we do still need a proper discussion of what are the corre= ct mechanisms going forward. I'd note at the moment, and from my perspective, that in terms of public vi= sible support there is not enough momentum for any of the options going for= ward - that I guess is partly because noone has called for it, but I certai= nly don't want any of the options allocated to BFCPBIS and find that noone = is interested in reviewing the documents. At the moment the ADs have indicated the DISPATCH list as the consensus bui= lding forum for identifying this. That may change, but that is where the di= scussion needs to be for now. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings (fluffy) > Sent: 02 March 2013 23:34 > To: Paul Kyzivat > Cc: dispatch@ietf.org; stephane.cazeaux@orange.com > Subject: Re: [dispatch] Remapping existing protocols for web usage: > websockets or data channels? >=20 >=20 > Part of my hope was that if all these things were on the BFCP list, we > could come to some sanity about what the optimal number of options are. >=20 >=20 > On Feb 24, 2013, at 3:43 PM, Paul Kyzivat wrote: >=20 > > On 2/24/13 5:28 PM, stephane.cazeaux@orange.com wrote: > >> That was my understanding. My point is that on the browser, the data > >> channel is part of the webrtc stuff. While websocket is to me more > >> suitable for such browser to server exchange. > >> Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE > >> endpoint since, unless I am wrong, a CLUE endpoint will also have to > >> support bfcp over tcp (or udp) to interwork with legacy ? > > > > First, AFAIK there are currently no plans to put bfcp over a data > channel, but I think there should be. > > > > My reason is because that is a mechanism that could be supported by a a= n > RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint ma= y > still need to support bfcp over tcp or udp for legacy interworking. > > > > It would also be possible for an RTCWEB clue client to use bfcp over a > websocket. > > > > The question is: how many of these alternatives do we want to define an= d > then ask people to support in their products. The more alternatives we > have the less likely we are to get interoperability. > > > > We have now started down the path of remapping existing protocols (firs= t > SIP, then MSRP, now maybe BFCP) over websockets. Meanwhile RTCWEB is > defining data channels over SCTP and and CLUE is tentatively planning to > put its protocol over that. So maybe we had better have a discussion of > where we are trying to go, and if what we are doing will get us to a good > place. > > > > Thanks, > > Paul > > > >> St=E9phane. > >> ----------------------------------------------------------------------= - > - > >> De : Paul Kyzivat > >> Envoy=E9 : 24/02/2013 02:32 > >> =C0 : CAZEAUX Stephane OLNC/OLPS > >> Cc : dispatch@ietf.org > >> Objet : Re: [dispatch] FW: New Version Notification for > >> draft-pascual-dispatch-bfcp-websocket-00.txt > >> > >> On 2/22/13 11:40 AM, stephane.cazeaux@orange.com wrote: > >>> Hi Paul, > >>> > >>> Having BFCP over data channel would limit the applicability of BFCP t= o > webrtc (other formulation: it would require the webrtc framework to get > BFCP in the browser), while we might want to have BFCP protocol in web > client outside of webrtc. > >> > >> I guess I didn't explain myself well enough. > >> > >> What I am suggesting is bfcp over the DTLS/SCTP stack that is being > used > >> for RTCWEB data channels, and that the mechanisms used to negotiate th= e > >> stream numbers for each direction be compatible with RTCWEB. In this > way > >> a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.g= . > >> C-based) implementation is also possible. > >> > >> This is the same direction we are investigating for the clue data > channel. > >> > >> The term "data channel" here is perhaps overloaded, because it could > >> mean a real RTCWEB data channel, or something similar for other > >> environments. Ideally we would just use SCTP terms, but it has no term > >> for a bidirectional "channel", only unidirectional streams. But this > >> should end up being formalized in the SDP. > >> > >> Thanks, > >> Paul > >> > >>> St=E9phane. > >>> > >>> -----Message d'origine----- > >>> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>> Envoy=E9 : jeudi 21 f=E9vrier 2013 22:32 > >>> =C0 : dispatch@ietf.org > >>> Objet : Re: [dispatch] FW: New Version Notification for draft-pascual= - > dispatch-bfcp-websocket-00.txt > >>> > >>> Victor, > >>> > >>> A question for you: > >>> > >>> Another possibility is to map bfcp over a data channel as being > specified for rtcweb. > >>> > >>> If that were done, would it be a suitable alternative to bfcp over > websocket? > >>> > >>> We are also going to need bfcp support in conjunction with CLUE. > >>> And CLUE is going to have its own data channel. We are aiming to use > an rtcweb-compatible data channel so that we can have rtcweb browser base= d > clue clients. > >>> > >>> If bfcp also worked over a data channel, then these multiple uses of > data channels could all coexist on a single SCTP association. And they > could work the same regardless of whether or not there are web clients. > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 2/21/13 12:38 PM, Victor Pascual Avila wrote: > >>>> Hi all, > >>>> > >>>> We have submitted a new Internet draft to describe the WebSocket > >>>> Protocol as a Transport for the Binary Floor Control Protocol (BFCP)= . > >>>> We are looking forward to your review comments. > >>>> > >>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 > >>>> > >>>> Best regards, > >>>> -Victor > >>>> > >>>> > >>>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" > >>>> > >>>> wrote: > >>>> > >>>>> > >>>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt > >>>>> has been successfully submitted by Victor Pascual and posted to the > >>>>> IETF repository. > >>>>> > >>>>> Filename: draft-pascual-dispatch-bfcp-websocket > >>>>> Revision: 00 > >>>>> Title: The WebSocket Protocol as a Transport for the Binar= y > Floor > >>>>> Control Protocol (BFCP) > >>>>> Creation date: 2013-02-15 > >>>>> Group: Individual Submission > >>>>> Number of pages: 9 > >>>>> URL: > >>>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp- > webso > >>>>> cket- > >>>>> 00.txt > >>>>> Status: > >>>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp- > websocket > >>>>> Htmlized: > >>>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 > >>>>> > >>>>> > >>>>> Abstract: > >>>>> The WebSocket protocol enables two-way realtime communication > between > >>>>> clients and servers. This document specifies a new WebSocket > sub- > >>>>> protocol as a reliable transport mechanism between Binary Floor > >>>>> Control Protocol (BFCP) entities to enable usage of BFCP in new > >>>>> scenarios. This document normatively updates > >>>>> [I-D.draft-ietf-bfcpbis-rfc4582bis] and > >>>>> [I-D.draft-ietf-bfcpbis-rfc4583bis] > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> The IETF Secretariat > >>>>> > >>>> _______________________________________________ > >>>> 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 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From emcho@sip-communicator.org Sun Mar 3 04:32:16 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C30521F86BC for ; Sun, 3 Mar 2013 04:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h114tP0ujvT3 for ; Sun, 3 Mar 2013 04:32:15 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id ECC8D21F86AF for ; Sun, 3 Mar 2013 04:32:14 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so3266361eek.20 for ; Sun, 03 Mar 2013 04:32:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=S1a9HRGggGQMg65rf6Qa0U+8/ew9cA2N2rDAXPK/yLs=; b=Lm6dqauTm8TS6D8H3Xp6/3DNDsuu23MofGC9+68dBmkmI8/c5UMM4CbQe9Efm3AxIR ng1BGJ6BHLYcgirwWs2g9ZKbfDg5jeozQc+uXhmm/uI1GLvsxf6+KIU4YQU3V4AhZLUr ERhWPRJohhwZqPqZt5iGwwi7BbDTHLHIsfGVj3QsEUMBGohB7Eofgg12DvdtWiW7PAgd TKxe1lVnBdmadBOp0bi6xUw7DtAFaZXvFdCD09ky4Dw0kvbFnSDqq5dz9sWT07EcxsF4 0gFo+uyMTFxuqP4ZhgUy+fz04mgdfiMjrFYBPRl/CHLz8u+azsx4JKX1TtE9s5s4sAzM WdOg== X-Received: by 10.14.214.66 with SMTP id b42mr47836309eep.34.1362313933990; Sun, 03 Mar 2013 04:32:13 -0800 (PST) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx.google.com with ESMTPS id k7sm26946539een.8.2013.03.03.04.32.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 04:32:13 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id b15so3249838eek.39 for ; Sun, 03 Mar 2013 04:32:13 -0800 (PST) X-Received: by 10.14.111.72 with SMTP id v48mr18108470eeg.11.1362313932938; Sun, 03 Mar 2013 04:32:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.123.79 with HTTP; Sun, 3 Mar 2013 04:31:51 -0800 (PST) In-Reply-To: References: <51102D21.10503@stpeter.im> From: Emil Ivov Date: Sun, 3 Mar 2013 14:31:51 +0200 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmMDdqQVihmump1kPyLMylPIF6GgXLgaM8CKrQVYimRROfj9oQLLVX0YgmubnmH25XAvDAs Cc: "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 12:32:16 -0000 Hey Cullen, On Sun, Mar 3, 2013 at 1:33 AM, Cullen Jennings (fluffy) wrote: > > > I'd be fascinated to hear the need for this As Peter already mentioned: we need to be able to match an incoming INVITE to a JID so we are looking for the most convenient way to do this without defining a new header. Partially because we'd like to keep all this as an informational effort and in part because, as you said it your self in Vancouver: there has to be an existing header that we could use for this. > - PAI is such a disaster zone that I'd want to make sure the envisioned > usage did not run into the many land mines around PAI. It might be that > some other header might meet the needs better than PAI. Well right now we basically say that if you are operating in a trusted domain, then you use PAI, if not you can still use P-Preferred-Identity as an indication but then you still have to validate that the JID from PPI has a vCard that matches the caller. In other words, you still have to get the vCard but at least you can do so for a single contact and not your entire roster. > Cullen - co-authors of the ill fated RFC 3325 > > PS - you might want consider the "Call-Info" header - OK, this does look like it could also do the job and we even have the "card" info-param. Thanks for the tip! > it would be very cool to the have HTTP URL in that pointed at the > JSON vCard for the user. Does it have to be HTTP? Would it make sense to use it with an xmpp: URI? The grammar seems to allow for a generic URI and I don't think there would be much ambiguity in a header that looks like this: Call-Info: ;purpose=card It seems like this could only mean that Alice's vCard can be retrieved through XMPP and it would probably be safe to infer that the XMPP URI mentioned there is her own JID (and "safe to infer" is really what this draft is all about). WDYT? I am also wondering if we should repeat the URI with purpose=icon in order to get the XMPP avatar or if having "card" one would suffice. Finally, we'd still need to keep the requirement for a cross check: whatever Call-Info says, one needs to download that vCard and make sure that a number in there matches the source of the current call. Otherwise this can be an attack. Cheers, Emil > > On Feb 4, 2013, at 3:50 PM, Peter Saint-Andre wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Dear DISPATCHers, > > > > At the XMPP Summit last week, for various reasons that aren't > > particularly relevant here, we talked a bit about how to include an > > XMPP address in the header of a SIP message. Folks at the meeting > > concluded that the P-Asserted-Identity header would work quite well > > (certainly better than a second Contact header). Unfortunately, RFC > > 3225 defines the P-Asserted-Identity as follows: > > > > A P-Asserted-Identity header field value MUST consist of exactly one > > name-addr or addr-spec. There may be one or two P-Asserted-Identity > > values. If there is one value, it MUST be a sip, sips, or tel URI. > > If there are two values, one value MUST be a sip or sips URI and the > > other MUST be a tel URI. > > > > It's not clear to me why the definition restricts the scheme to sip, > > sips, or tel. Could someone provide some insight about that? Would > > things break if we allowed more URI schemes there, in particular the > > xmpp scheme? > > > > Thanks! > > > > Peter > > > > - -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg > > 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/ > > =lu3v > > -----END PGP SIGNATURE----- > > _______________________________________________ > > 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 -- Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From fluffy@cisco.com Sun Mar 3 05:12:30 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9265521F86F2 for ; Sun, 3 Mar 2013 05:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.286 X-Spam-Level: X-Spam-Status: No, score=-110.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtEmRu3ax+d3 for ; Sun, 3 Mar 2013 05:12:29 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6460A21F86CD for ; Sun, 3 Mar 2013 05:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5678; q=dns/txt; s=iport; t=1362316349; x=1363525949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aKlSFk7apNYYjWuKJVLbf6KWYFhAwEeGDbKf2jKhAgA=; b=k3cd9Q5CCMJzLkEG44G9xhCueRLUdY5hFkb2GtP3o4kk8HMdZghs4Y4o LAT9Vt9bXEu+FZd1FvSWe9Z68j4PI5+jtP7gf6fyqQJZkxJG4lXVI97iC PZB2eotwoEqxkpmyo+iGE6/z5JXj3iR3QppCwvHo2tsLYaCuI2/zkOYO0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGZLM1GtJV2a/2dsb2JhbAA7CcJJfBZzgh8BAQEDAQEBAWsLBQkCAgEIDgoKJBsMCyUCBA4FCAGIBAYMxlMEjU+BFwILBCIHgl9hA4g2ik2EYY9OgwiBayQY X-IronPort-AV: E=Sophos;i="4.84,774,1355097600"; d="scan'208";a="183166635" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 03 Mar 2013 13:12:29 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r23DCS6r022837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Mar 2013 13:12:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Sun, 3 Mar 2013 07:12:28 -0600 From: "Cullen Jennings (fluffy)" To: Emil Ivov Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity Thread-Index: AQHOGAsUJhdVcbJHkUyhphnvwmWC1JiUVgCA Date: Sun, 3 Mar 2013 13:12:27 +0000 Message-ID: References: <51102D21.10503@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.11.190] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4E3FE14E4BF7C54D830C17CD4A4D7FA3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 13:12:30 -0000 If you don't want to do the vcard but just want the xmpp address directly, = I'd probably suggest something like=20 Call-Info: ;purpose=3Dimpp To just indicate that the URL provided the IM and Presence service for that= user RFC 3261 section 20.9 says that the IANA section of 3261 will define how to= add a new purpose but as far as I can tell it does not. However, the IANA = SIP registry for the URI purpose at http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-param= eters-13 is just spec required so I think think you might be able to trivial add a "= impp" purpose.=20 As a side note, I'm very much in favor of the SIP messages being able to pr= ovide the XMPP address related to the user so glad to see this work getting= done. Cullen PS - Seriously, PAI is not the header your are looking for.=20 On Mar 3, 2013, at 6:31 AM, Emil Ivov wrote: > Hey Cullen, >=20 > On Sun, Mar 3, 2013 at 1:33 AM, Cullen Jennings (fluffy) > wrote: >>=20 >>=20 >> I'd be fascinated to hear the need for this >=20 > As Peter already mentioned: we need to be able to match an incoming > INVITE to a JID so we are looking for the most convenient way to do > this without defining a new header. Partially because we'd like to > keep all this as an informational effort and in part because, as you > said it your self in Vancouver: there has to be an existing header > that we could use for this. >=20 >> - PAI is such a disaster zone that I'd want to make sure the envisioned >> usage did not run into the many land mines around PAI. It might be that >> some other header might meet the needs better than PAI. >=20 > Well right now we basically say that if you are operating in a trusted > domain, then you use PAI, if not you can still use > P-Preferred-Identity as an indication but then you still have to > validate that the JID from PPI has a vCard that matches the caller. In > other words, you still have to get the vCard but at least you can do > so for a single contact and not your entire roster. >=20 >> Cullen - co-authors of the ill fated RFC 3325 >>=20 >> PS - you might want consider the "Call-Info" header - >=20 > OK, this does look like it could also do the job and we even have the > "card" info-param. Thanks for the tip! >=20 >> it would be very cool to the have HTTP URL in that pointed at the >> JSON vCard for the user. >=20 > Does it have to be HTTP? Would it make sense to use it with an xmpp: > URI? The grammar seems to allow for a generic URI and I don't think > there would be much ambiguity in a header that looks like this: >=20 > Call-Info: ;purpose=3Dcard >=20 > It seems like this could only mean that Alice's vCard can be retrieved > through XMPP and it would probably be safe to infer that the XMPP URI > mentioned there is her own JID (and "safe to infer" is really what > this draft is all about). WDYT? >=20 > I am also wondering if we should repeat the URI with purpose=3Dicon in > order to get the XMPP avatar or if having "card" one would suffice. >=20 > Finally, we'd still need to keep the requirement for a cross check: > whatever Call-Info says, one needs to download that vCard and make > sure that a number in there matches the source of the current call. > Otherwise this can be an attack. >=20 > Cheers, > Emil >=20 >=20 >>=20 >> On Feb 4, 2013, at 3:50 PM, Peter Saint-Andre wrote= : >>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>>=20 >>> Dear DISPATCHers, >>>=20 >>> At the XMPP Summit last week, for various reasons that aren't >>> particularly relevant here, we talked a bit about how to include an >>> XMPP address in the header of a SIP message. Folks at the meeting >>> concluded that the P-Asserted-Identity header would work quite well >>> (certainly better than a second Contact header). Unfortunately, RFC >>> 3225 defines the P-Asserted-Identity as follows: >>>=20 >>> A P-Asserted-Identity header field value MUST consist of exactly one >>> name-addr or addr-spec. There may be one or two P-Asserted-Identity >>> values. If there is one value, it MUST be a sip, sips, or tel URI. >>> If there are two values, one value MUST be a sip or sips URI and the >>> other MUST be a tel URI. >>>=20 >>> It's not clear to me why the definition restricts the scheme to sip, >>> sips, or tel. Could someone provide some insight about that? Would >>> things break if we allowed more URI schemes there, in particular the >>> xmpp scheme? >>>=20 >>> Thanks! >>>=20 >>> Peter >>>=20 >>> - -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>>=20 >>>=20 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>=20 >>> iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg >>> 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/ >>> =3Dlu3v >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> 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 >=20 >=20 >=20 >=20 > -- > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > Jitsi > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > http://jitsi.org FAX: +33.1.77.62.47.31 From emil@sip-communicator.org Sun Mar 3 08:08:35 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAF421F8726 for ; Sun, 3 Mar 2013 08:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XayLjcr5WP7A for ; Sun, 3 Mar 2013 08:08:34 -0800 (PST) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by ietfa.amsl.com (Postfix) with ESMTP id 32DE721F8715 for ; Sun, 3 Mar 2013 08:08:33 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id jf20so2020114bkc.21 for ; Sun, 03 Mar 2013 08:08:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Q6apWngRuAcjFPUgqAYg7p3JiXMRQRBuPxYZ+E9vXkw=; b=JRJmKd0yqgMXTnWgT541VWV6WMusGdm4/Xb7d3M6xKYoYmme1ua2+eisnOlGef1O09 OHiCO1d6+4HiiupG2sYFDdiFhma+xtvLSebBR4/lbdxxthMB8Sa9xiyTuQJN6zApQWet 1QWPjSfhkbXNdNtvxO+4zosrqC5zh1uEdIgcPGZXzArar+wLOy2F1TJTgQzxJ8/6msqR uzBr7mmApjg+iKSHyuhm+mls+wL/4bzZ8b51Z1llv0q3QIzFBuIXoYDrJs1Pv/8/GhXq 8jtBaHh8LI+JK+bDtTn/PfQSrAZ2IS5LtqS6lg8aEMhhhzzEjBJiUGxEcR6VjOqcHlxn wXAA== X-Received: by 10.204.11.212 with SMTP id u20mr6087396bku.55.1362326912942; Sun, 03 Mar 2013 08:08:32 -0800 (PST) Received: from camionet.local (77-85-164-78.btc-net.bg. [77.85.164.78]) by mx.google.com with ESMTPS id ge12sm4815095bkc.19.2013.03.03.08.08.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 08:08:31 -0800 (PST) Message-ID: <5133757C.90908@jitsi.org> Date: Sun, 03 Mar 2013 18:08:28 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <51102D21.10503@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmTgGH38SKLRieY/c1w0NrG3MXZTp0nNZaDvl3ZA6UWqwUonZhcuOZnnsPV0iCm4WxBxTR4 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 16:08:36 -0000 On 03.03.13, 15:12, Cullen Jennings (fluffy) wrote: > > If you don't want to do the vcard On the contrary, vCard seems quite reasonable to me. I am also comfortable with using the xmpp: address in such a vCard as a general IMPP address. Do you see a problem with it? > but just want the xmpp address directly, I'd probably suggest something like > > Call-Info: ;purpose=impp > > To just indicate that the URL provided the IM and Presence service for that user > > RFC 3261 section 20.9 says that the IANA section of 3261 will define how to add a new purpose but as far as I can tell it does not. However, the IANA SIP registry for the URI purpose at > > http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-13 > > is just spec required so I think think you might be able to trivial add a "impp" purpose. Even if it is trivial, can we actually do that from an informational document? > As a side note, I'm very much in favor of the SIP messages being able to provide the XMPP address related to the user so glad to see this work getting done. Great! Thanks for your support. > Cullen > > PS - Seriously, PAI is not the header your are looking for. OK sure. We weren't particularly stuck on it anyway. It did seem to be somewhat overloaded and if we can just do a "card" XMPP URI in a Call-Info then this really seems like the easiest way forward. Cheers, Emil > > > > On Mar 3, 2013, at 6:31 AM, Emil Ivov > wrote: > >> Hey Cullen, >> >> On Sun, Mar 3, 2013 at 1:33 AM, Cullen Jennings (fluffy) >> wrote: >>> >>> >>> I'd be fascinated to hear the need for this >> >> As Peter already mentioned: we need to be able to match an incoming >> INVITE to a JID so we are looking for the most convenient way to do >> this without defining a new header. Partially because we'd like to >> keep all this as an informational effort and in part because, as you >> said it your self in Vancouver: there has to be an existing header >> that we could use for this. >> >>> - PAI is such a disaster zone that I'd want to make sure the envisioned >>> usage did not run into the many land mines around PAI. It might be that >>> some other header might meet the needs better than PAI. >> >> Well right now we basically say that if you are operating in a trusted >> domain, then you use PAI, if not you can still use >> P-Preferred-Identity as an indication but then you still have to >> validate that the JID from PPI has a vCard that matches the caller. In >> other words, you still have to get the vCard but at least you can do >> so for a single contact and not your entire roster. >> >>> Cullen - co-authors of the ill fated RFC 3325 >>> >>> PS - you might want consider the "Call-Info" header - >> >> OK, this does look like it could also do the job and we even have the >> "card" info-param. Thanks for the tip! >> >>> it would be very cool to the have HTTP URL in that pointed at the >>> JSON vCard for the user. >> >> Does it have to be HTTP? Would it make sense to use it with an xmpp: >> URI? The grammar seems to allow for a generic URI and I don't think >> there would be much ambiguity in a header that looks like this: >> >> Call-Info: ;purpose=card >> >> It seems like this could only mean that Alice's vCard can be retrieved >> through XMPP and it would probably be safe to infer that the XMPP URI >> mentioned there is her own JID (and "safe to infer" is really what >> this draft is all about). WDYT? >> >> I am also wondering if we should repeat the URI with purpose=icon in >> order to get the XMPP avatar or if having "card" one would suffice. >> >> Finally, we'd still need to keep the requirement for a cross check: >> whatever Call-Info says, one needs to download that vCard and make >> sure that a number in there matches the source of the current call. >> Otherwise this can be an attack. >> >> Cheers, >> Emil >> >> >>> >>> On Feb 4, 2013, at 3:50 PM, Peter Saint-Andre wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Dear DISPATCHers, >>>> >>>> At the XMPP Summit last week, for various reasons that aren't >>>> particularly relevant here, we talked a bit about how to include an >>>> XMPP address in the header of a SIP message. Folks at the meeting >>>> concluded that the P-Asserted-Identity header would work quite well >>>> (certainly better than a second Contact header). Unfortunately, RFC >>>> 3225 defines the P-Asserted-Identity as follows: >>>> >>>> A P-Asserted-Identity header field value MUST consist of exactly one >>>> name-addr or addr-spec. There may be one or two P-Asserted-Identity >>>> values. If there is one value, it MUST be a sip, sips, or tel URI. >>>> If there are two values, one value MUST be a sip or sips URI and the >>>> other MUST be a tel URI. >>>> >>>> It's not clear to me why the definition restricts the scheme to sip, >>>> sips, or tel. Could someone provide some insight about that? Would >>>> things break if we allowed more URI schemes there, in particular the >>>> xmpp scheme? >>>> >>>> Thanks! >>>> >>>> Peter >>>> >>>> - -- >>>> Peter Saint-Andre >>>> https://stpeter.im/ >>>> >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>> >>>> iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg >>>> 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/ >>>> =lu3v >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> 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 >> >> >> >> >> -- >> Emil Ivov, Ph.D. 67000 Strasbourg, >> Project Lead France >> Jitsi >> emcho@jitsi.org PHONE: +33.1.77.62.43.30 >> http://jitsi.org FAX: +33.1.77.62.47.31 > > -- https://jitsi.org From pkyzivat@alum.mit.edu Sun Mar 3 20:58:11 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CCB21F86DD for ; Sun, 3 Mar 2013 20:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.162 X-Spam-Level: ** X-Spam-Status: No, score=2.162 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 q3c3UAY3G9oS for ; Sun, 3 Mar 2013 20:58:07 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 59B3821F86D3 for ; Sun, 3 Mar 2013 20:58:07 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta08.westchester.pa.mail.comcast.net with comcast id 7GqQ1l0041ei1Bg58Gy6Mg; Mon, 04 Mar 2013 04:58:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 7Gy61l0093ZTu2S3kGy6S4; Mon, 04 Mar 2013 04:58:06 +0000 Message-ID: <513429DD.9010606@alum.mit.edu> Date: Mon, 04 Mar 2013 12:58:05 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> , <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362373086; bh=CP2yYe8Paqq+oNJWIqDvEPJ3sqtqognBN5+gdWmBEXY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GIytdCGpMYVgM1NefK4aj2LRoFpZD6qcEA2obAdUMf9PivqQwDVeSBlGqHVfd2zZw lNzaTbWl82M3ocGcLMve9s5KQ7IlhcXuxVCu7Bc0FoDkIkNKVBILzZqEykKNOsOgoU g4SUWW4W/SiqjISiwQn3ERllx0U6GtfMZXQn/FM/+u9d1aR2mKN1rfkdJcTwt0JYTz 7Klg2Bt3Q4/KsloehpvmfGesbqSLUriPUdcqtYnmoUQ2sVQzgrWVAyBkstb4aAx9aL pjjmXBvLxF21e3JEBg/F+pZVUwIjl3GsLs89fp9vQuH9froLl0+aWq6+l7jzp2uYNH FDPlapHFnLJeQ== Cc: "Cullen Jennings \(fluffy\)" , "dispatch@ietf.org" , "stephane.cazeaux@orange.com" Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 04:58:11 -0000 I didn't mean to suggest that there is any interest in doing this in bfcpbis, or that thre should be. I have been inquiring around a bit just to sense if there is any sort of interest. And at the same time wantching these various one-off activities re websockets. I agree that dispatch is a likely place to start discussing this. And I think it may be best to start discussing it in general rather than treating each case independently. It is probably premature, and too late, to do anything formal about this in Orlando. But we might want to talk about it informally, over beer. Thanks, Paul On 3/3/13 7:32 PM, DRAGE, Keith (Keith) wrote: > At the moment these things are out of scope of BFCPBIS as the charter as currently worded would prevent this. > > But I agree that we do still need a proper discussion of what are the correct mechanisms going forward. > > I'd note at the moment, and from my perspective, that in terms of public visible support there is not enough momentum for any of the options going forward - that I guess is partly because noone has called for it, but I certainly don't want any of the options allocated to BFCPBIS and find that noone is interested in reviewing the documents. > > At the moment the ADs have indicated the DISPATCH list as the consensus building forum for identifying this. That may change, but that is where the discussion needs to be for now. > > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Cullen Jennings (fluffy) >> Sent: 02 March 2013 23:34 >> To: Paul Kyzivat >> Cc: dispatch@ietf.org; stephane.cazeaux@orange.com >> Subject: Re: [dispatch] Remapping existing protocols for web usage: >> websockets or data channels? >> >> >> Part of my hope was that if all these things were on the BFCP list, we >> could come to some sanity about what the optimal number of options are. >> >> >> On Feb 24, 2013, at 3:43 PM, Paul Kyzivat wrote: >> >>> On 2/24/13 5:28 PM, stephane.cazeaux@orange.com wrote: >>>> That was my understanding. My point is that on the browser, the data >>>> channel is part of the webrtc stuff. While websocket is to me more >>>> suitable for such browser to server exchange. >>>> Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE >>>> endpoint since, unless I am wrong, a CLUE endpoint will also have to >>>> support bfcp over tcp (or udp) to interwork with legacy ? >>> >>> First, AFAIK there are currently no plans to put bfcp over a data >> channel, but I think there should be. >>> >>> My reason is because that is a mechanism that could be supported by a an >> RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint may >> still need to support bfcp over tcp or udp for legacy interworking. >>> >>> It would also be possible for an RTCWEB clue client to use bfcp over a >> websocket. >>> >>> The question is: how many of these alternatives do we want to define and >> then ask people to support in their products. The more alternatives we >> have the less likely we are to get interoperability. >>> >>> We have now started down the path of remapping existing protocols (first >> SIP, then MSRP, now maybe BFCP) over websockets. Meanwhile RTCWEB is >> defining data channels over SCTP and and CLUE is tentatively planning to >> put its protocol over that. So maybe we had better have a discussion of >> where we are trying to go, and if what we are doing will get us to a good >> place. >>> >>> Thanks, >>> Paul >>> >>>> Stéphane. >>>> ----------------------------------------------------------------------- >> - >>>> De : Paul Kyzivat >>>> Envoyé : 24/02/2013 02:32 >>>> À : CAZEAUX Stephane OLNC/OLPS >>>> Cc : dispatch@ietf.org >>>> Objet : Re: [dispatch] FW: New Version Notification for >>>> draft-pascual-dispatch-bfcp-websocket-00.txt >>>> >>>> On 2/22/13 11:40 AM, stephane.cazeaux@orange.com wrote: >>>>> Hi Paul, >>>>> >>>>> Having BFCP over data channel would limit the applicability of BFCP to >> webrtc (other formulation: it would require the webrtc framework to get >> BFCP in the browser), while we might want to have BFCP protocol in web >> client outside of webrtc. >>>> >>>> I guess I didn't explain myself well enough. >>>> >>>> What I am suggesting is bfcp over the DTLS/SCTP stack that is being >> used >>>> for RTCWEB data channels, and that the mechanisms used to negotiate the >>>> stream numbers for each direction be compatible with RTCWEB. In this >> way >>>> a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.g. >>>> C-based) implementation is also possible. >>>> >>>> This is the same direction we are investigating for the clue data >> channel. >>>> >>>> The term "data channel" here is perhaps overloaded, because it could >>>> mean a real RTCWEB data channel, or something similar for other >>>> environments. Ideally we would just use SCTP terms, but it has no term >>>> for a bidirectional "channel", only unidirectional streams. But this >>>> should end up being formalized in the SDP. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Stéphane. >>>>> >>>>> -----Message d'origine----- >>>>> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Envoyé : jeudi 21 février 2013 22:32 >>>>> À : dispatch@ietf.org >>>>> Objet : Re: [dispatch] FW: New Version Notification for draft-pascual- >> dispatch-bfcp-websocket-00.txt >>>>> >>>>> Victor, >>>>> >>>>> A question for you: >>>>> >>>>> Another possibility is to map bfcp over a data channel as being >> specified for rtcweb. >>>>> >>>>> If that were done, would it be a suitable alternative to bfcp over >> websocket? >>>>> >>>>> We are also going to need bfcp support in conjunction with CLUE. >>>>> And CLUE is going to have its own data channel. We are aiming to use >> an rtcweb-compatible data channel so that we can have rtcweb browser based >> clue clients. >>>>> >>>>> If bfcp also worked over a data channel, then these multiple uses of >> data channels could all coexist on a single SCTP association. And they >> could work the same regardless of whether or not there are web clients. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 2/21/13 12:38 PM, Victor Pascual Avila wrote: >>>>>> Hi all, >>>>>> >>>>>> We have submitted a new Internet draft to describe the WebSocket >>>>>> Protocol as a Transport for the Binary Floor Control Protocol (BFCP). >>>>>> We are looking forward to your review comments. >>>>>> >>>>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>>>>> >>>>>> Best regards, >>>>>> -Victor >>>>>> >>>>>> >>>>>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" >>>>>> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt >>>>>>> has been successfully submitted by Victor Pascual and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Filename: draft-pascual-dispatch-bfcp-websocket >>>>>>> Revision: 00 >>>>>>> Title: The WebSocket Protocol as a Transport for the Binary >> Floor >>>>>>> Control Protocol (BFCP) >>>>>>> Creation date: 2013-02-15 >>>>>>> Group: Individual Submission >>>>>>> Number of pages: 9 >>>>>>> URL: >>>>>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp- >> webso >>>>>>> cket- >>>>>>> 00.txt >>>>>>> Status: >>>>>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp- >> websocket >>>>>>> Htmlized: >>>>>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>>>>>> >>>>>>> >>>>>>> Abstract: >>>>>>> The WebSocket protocol enables two-way realtime communication >> between >>>>>>> clients and servers. This document specifies a new WebSocket >> sub- >>>>>>> protocol as a reliable transport mechanism between Binary Floor >>>>>>> Control Protocol (BFCP) entities to enable usage of BFCP in new >>>>>>> scenarios. This document normatively updates >>>>>>> [I-D.draft-ietf-bfcpbis-rfc4582bis] and >>>>>>> [I-D.draft-ietf-bfcpbis-rfc4583bis] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 > From oej@edvina.net Mon Mar 4 00:51:58 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F7821F8925 for ; Mon, 4 Mar 2013 00:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 CYic5Bwe+UVk for ; Mon, 4 Mar 2013 00:51:52 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3FC21F88DD for ; Mon, 4 Mar 2013 00:51:50 -0800 (PST) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id BBD5E93DE3C; Mon, 4 Mar 2013 08:51:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 4 Mar 2013 09:51:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51102D21.10503@stpeter.im> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1499) Cc: Emil Ivov , "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 08:51:58 -0000 3 mar 2013 kl. 14:12 skrev "Cullen Jennings (fluffy)" = : >=20 > If you don't want to do the vcard but just want the xmpp address = directly, I'd probably suggest something like=20 >=20 > Call-Info: ;purpose=3Dimpp >=20 > To just indicate that the URL provided the IM and Presence service for = that user >=20 > RFC 3261 section 20.9 says that the IANA section of 3261 will define = how to add a new purpose but as far as I can tell it does not. However, = the IANA SIP registry for the URI purpose at >=20 > = http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-para= meters-13 >=20 > is just spec required so I think think you might be able to trivial = add a "impp" purpose.=20 Shouldn't the purposes in RFC 3261 be added to that registry too? /O >=20 > As a side note, I'm very much in favor of the SIP messages being able = to provide the XMPP address related to the user so glad to see this work = getting done. >=20 > Cullen >=20 > PS - Seriously, PAI is not the header your are looking for.=20 >=20 >=20 >=20 > On Mar 3, 2013, at 6:31 AM, Emil Ivov > wrote: >=20 >> Hey Cullen, >>=20 >> On Sun, Mar 3, 2013 at 1:33 AM, Cullen Jennings (fluffy) >> wrote: >>>=20 >>>=20 >>> I'd be fascinated to hear the need for this >>=20 >> As Peter already mentioned: we need to be able to match an incoming >> INVITE to a JID so we are looking for the most convenient way to do >> this without defining a new header. Partially because we'd like to >> keep all this as an informational effort and in part because, as you >> said it your self in Vancouver: there has to be an existing header >> that we could use for this. >>=20 >>> - PAI is such a disaster zone that I'd want to make sure the = envisioned >>> usage did not run into the many land mines around PAI. It might be = that >>> some other header might meet the needs better than PAI. >>=20 >> Well right now we basically say that if you are operating in a = trusted >> domain, then you use PAI, if not you can still use >> P-Preferred-Identity as an indication but then you still have to >> validate that the JID from PPI has a vCard that matches the caller. = In >> other words, you still have to get the vCard but at least you can do >> so for a single contact and not your entire roster. >>=20 >>> Cullen - co-authors of the ill fated RFC 3325 >>>=20 >>> PS - you might want consider the "Call-Info" header - >>=20 >> OK, this does look like it could also do the job and we even have the >> "card" info-param. Thanks for the tip! >>=20 >>> it would be very cool to the have HTTP URL in that pointed at the >>> JSON vCard for the user. >>=20 >> Does it have to be HTTP? Would it make sense to use it with an xmpp: >> URI? The grammar seems to allow for a generic URI and I don't think >> there would be much ambiguity in a header that looks like this: >>=20 >> Call-Info: ;purpose=3Dcard >>=20 >> It seems like this could only mean that Alice's vCard can be = retrieved >> through XMPP and it would probably be safe to infer that the XMPP URI >> mentioned there is her own JID (and "safe to infer" is really what >> this draft is all about). WDYT? >>=20 >> I am also wondering if we should repeat the URI with purpose=3Dicon = in >> order to get the XMPP avatar or if having "card" one would suffice. >>=20 >> Finally, we'd still need to keep the requirement for a cross check: >> whatever Call-Info says, one needs to download that vCard and make >> sure that a number in there matches the source of the current call. >> Otherwise this can be an attack. >>=20 >> Cheers, >> Emil >>=20 >>=20 >>>=20 >>> On Feb 4, 2013, at 3:50 PM, Peter Saint-Andre = wrote: >>>=20 >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>>=20 >>>> Dear DISPATCHers, >>>>=20 >>>> At the XMPP Summit last week, for various reasons that aren't >>>> particularly relevant here, we talked a bit about how to include an >>>> XMPP address in the header of a SIP message. Folks at the meeting >>>> concluded that the P-Asserted-Identity header would work quite well >>>> (certainly better than a second Contact header). Unfortunately, RFC >>>> 3225 defines the P-Asserted-Identity as follows: >>>>=20 >>>> A P-Asserted-Identity header field value MUST consist of exactly = one >>>> name-addr or addr-spec. There may be one or two = P-Asserted-Identity >>>> values. If there is one value, it MUST be a sip, sips, or tel URI. >>>> If there are two values, one value MUST be a sip or sips URI and = the >>>> other MUST be a tel URI. >>>>=20 >>>> It's not clear to me why the definition restricts the scheme to = sip, >>>> sips, or tel. Could someone provide some insight about that? Would >>>> things break if we allowed more URI schemes there, in particular = the >>>> xmpp scheme? >>>>=20 >>>> Thanks! >>>>=20 >>>> Peter >>>>=20 >>>> - -- >>>> Peter Saint-Andre >>>> https://stpeter.im/ >>>>=20 >>>>=20 >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>>=20 >>>> iEYEARECAAYFAlEQLSEACgkQNL8k5A2w/vyr8ACfcAqzu+1ceGZxu0qvQLECL4rg >>>> 6DIAoMFh0zKEs2sjN1R3yUy6HyJGU2N/ >>>> =3Dlu3v >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> 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 >>=20 >>=20 >>=20 >>=20 >> -- >> Emil Ivov, Ph.D. 67000 Strasbourg, >> Project Lead France >> Jitsi >> emcho@jitsi.org PHONE: +33.1.77.62.43.30 >> http://jitsi.org FAX: +33.1.77.62.47.31 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From sergio.garcia.murillo@gmail.com Mon Mar 4 03:48:52 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24E921F8936 for ; Mon, 4 Mar 2013 03:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=3.239, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 V23d2OtfnIjl for ; Mon, 4 Mar 2013 03:48:51 -0800 (PST) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3021F8A6E for ; Mon, 4 Mar 2013 03:48:50 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b47so3724429eek.1 for ; Mon, 04 Mar 2013 03:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0AU/3Gc7ifj+3NPxnlzaeqlVN9oZfetd9SqL0M6OfvA=; b=Mtx8HQH9oaK7yYrI2VCv6dG9JzlX1AZafGNMZIEbrl8xrSTPu4mz4ElX05KVIRolKv F0INtgiPDh2Ce4Z15o8yNipNa7IgGNJMfIK2Zkb8UT+JnPRmgf4/HEA1R9wpY0Wt0tHx vjhi3NLq/O2MHzU26WJl4XHb/9qAlGSvlzoxKuswG5JfArWYv/yoWMjCmuZ7GqkxuOq9 IN2xapCwnPUD77YDVEDnP3QvVMSqTvUM94GA6Pyebx5WS+ECPTRd674Y0aZFXihDype4 Mtz+qk0RWmgV+PplTzhzzTfAPOKI3q1nsSkWWEDJhphYzbRymOWisI19ageiX1y2I+F3 TpQg== X-Received: by 10.14.3.133 with SMTP id 5mr57827825eeh.43.1362397729691; Mon, 04 Mar 2013 03:48:49 -0800 (PST) Received: from [192.168.1.49] (190.Red-95-122-190.staticIP.rima-tde.net. [95.122.190.190]) by mx.google.com with ESMTPS id z45sm11132687eeu.10.2013.03.04.03.48.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 03:48:48 -0800 (PST) Message-ID: <51348A28.8020009@gmail.com> Date: Mon, 04 Mar 2013 12:48:56 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: stephane.cazeaux@orange.com References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> In-Reply-To: <51348999.1000506@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 11:48:52 -0000 Hi all, I am interested in this topic to implement it in our MCU, so I can provide some real life feedback: http://www.medooze.com/products/mcu.aspx From my point of view, while the datachannels provides natural solutions for some of the issues of bfcp over websockets, implementing support for datachannels is an overkill when we just want to use bcfp. Also, there are quite a lot of clients not supporting bcfp natively, so we would like to provide those clients an alternative http interface to be able to provide the bcfp functionalities. In that scenario, datachannels will not be the best choice. So, as in our case, we will be implementing bcfp over websockets in any case to support this html interface, it would be great to be able to reuse the same implementation for webrtc clients (i.e exchanging the set up information in the sdp), and avoid the costs of implementing datachannels at all. Also, as a side discussion, regardless of the transport chosen, I don't see managing binary messages in the browser is something natural, if possible, it would be a good idea to add support for other serialization formats for bcfp messages more usable in browsers (i.e. json or xml). Best regards Sergio > ---------- Forwarded message ---------- > From: > Date: Sun, Feb 24, 2013 at 10:28 AM > Subject: Re: [dispatch] FW: New Version Notification for > draft-pascual-dispatch-bfcp-websocket-00.txt > To: pkyzivat@alum.mit.edu > Cc: dispatch@ietf.org > > > That was my understanding. My point is that on the browser, the data > channel is part of the webrtc stuff. While websocket is to me more > suitable for such browser to server exchange. > Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE > endpoint since, unless I am wrong, a CLUE endpoint will also have to > support bfcp over tcp (or udp) to interwork with legacy ? > > Stéphane. > ________________________________ > De : Paul Kyzivat > Envoyé : 24/02/2013 02:32 > À : CAZEAUX Stephane OLNC/OLPS > Cc : dispatch@ietf.org > > Objet : Re: [dispatch] FW: New Version Notification for > draft-pascual-dispatch-bfcp-websocket-00.txt > > On 2/22/13 11:40 AM, stephane.cazeaux@orange.com wrote: >> Hi Paul, >> >> Having BFCP over data channel would limit the applicability of BFCP >> to webrtc (other formulation: it would require the webrtc framework >> to get BFCP in the browser), while we might want to have BFCP >> protocol in web client outside of webrtc. > I guess I didn't explain myself well enough. > > What I am suggesting is bfcp over the DTLS/SCTP stack that is being used > for RTCWEB data channels, and that the mechanisms used to negotiate the > stream numbers for each direction be compatible with RTCWEB. In this way > a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.g. > C-based) implementation is also possible. > > This is the same direction we are investigating for the clue data > channel. > > The term "data channel" here is perhaps overloaded, because it could > mean a real RTCWEB data channel, or something similar for other > environments. Ideally we would just use SCTP terms, but it has no term > for a bidirectional "channel", only unidirectional streams. But this > should end up being formalized in the SDP. > > Thanks, > Paul > >> Stéphane. >> >> -----Message d'origine----- >> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Envoyé : jeudi 21 février 2013 22:32 >> À : dispatch@ietf.org >> Objet : Re: [dispatch] FW: New Version Notification for >> draft-pascual-dispatch-bfcp-websocket-00.txt >> >> Victor, >> >> A question for you: >> >> Another possibility is to map bfcp over a data channel as being >> specified for rtcweb. >> >> If that were done, would it be a suitable alternative to bfcp over >> websocket? >> >> We are also going to need bfcp support in conjunction with CLUE. >> And CLUE is going to have its own data channel. We are aiming to use >> an rtcweb-compatible data channel so that we can have rtcweb browser >> based clue clients. >> >> If bfcp also worked over a data channel, then these multiple uses of >> data channels could all coexist on a single SCTP association. And >> they could work the same regardless of whether or not there are web >> clients. >> >> Thanks, >> Paul >> >> On 2/21/13 12:38 PM, Victor Pascual Avila wrote: >>> Hi all, >>> >>> We have submitted a new Internet draft to describe the WebSocket >>> Protocol as a Transport for the Binary Floor Control Protocol (BFCP). >>> We are looking forward to your review comments. >>> >>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>> >>> Best regards, >>> -Victor >>> >>> >>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" >>> >>> wrote: >>> >>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt >>>> has been successfully submitted by Victor Pascual and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-pascual-dispatch-bfcp-websocket >>>> Revision: 00 >>>> Title: The WebSocket Protocol as a Transport for the >>>> Binary Floor >>>> Control Protocol (BFCP) >>>> Creation date: 2013-02-15 >>>> Group: Individual Submission >>>> Number of pages: 9 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-webso >>>> cket- >>>> 00.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>>> >>>> >>>> Abstract: >>>> The WebSocket protocol enables two-way realtime communication >>>> between >>>> clients and servers. This document specifies a new WebSocket >>>> sub- >>>> protocol as a reliable transport mechanism between Binary Floor >>>> Control Protocol (BFCP) entities to enable usage of BFCP in new >>>> scenarios. This document normatively updates >>>> [I-D.draft-ietf-bfcpbis-rfc4582bis] and >>>> [I-D.draft-ietf-bfcpbis-rfc4583bis] >>>> >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> _______________________________________________ >>> 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 prvs=8774b44e54=aallen@blackberry.com Sun Mar 3 14:53:40 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBFE21F88C1 for ; Sun, 3 Mar 2013 14:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 Jo18Q2DvPwFK for ; Sun, 3 Mar 2013 14:53:39 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 01D8C21F88BF for ; Sun, 3 Mar 2013 14:53:38 -0800 (PST) X-AuditID: 0a412830-b7f0a6d0000016df-9a-5133d4642146 Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 38.E7.05855.464D3315; Sun, 3 Mar 2013 16:53:24 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0328.009; Sun, 3 Mar 2013 16:53:23 -0600 From: Andrew Allen To: "Cullen Jennings (fluffy)" Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQHNx0LDMMCAzJYzhkOmkNSi4UyFuJhRn9YA//+gKOCAQtLGgIABHu6A Date: Sun, 3 Mar 2013 22:53:23 +0000 Message-ID: References: <50ABBAD6.9050103@gmail.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGKsWRmVeSWpSXmKPExsXC5Zyvo5tyxTjQoGmmrsXSSQtYLToms1ls Wr6SyeLC+l8sDiweU35vZPX49fUqm8fOWXfZPZYs+ckUwBLVwGiTlFhSFpyZnqdvZ5OYl5df kliSqpCSWpxsq+STmp6YoxBQlFmWmFyp4JJZnJyTmJmbWqSkkJliq2SipFCQk5icmpuaV2Kr lFhQkJqXomTHpYABbIDKMvMUUvOS81My89JtlTyD/XUtLEwtdQ2V7HQTOnkyTl3/ylQwU7/i 3qOJzA2MbWpdjBwcEgImEm/W1HYxcgKZYhIX7q1n62Lk4hASaGOSeHjpHZSziVHixs2zbCBV bAJaEvsPT2cCsUUEDCWa9sxjAiliFpjAKLH452V2EEdYoJlRYsPhDawQVS2MEvf+eEDYbhJX Oh+zg9gsAioSRx9/AJvEK+AhsenmDHaIdW8ZJRpWXGUFuY9TwFdi5h9HkBpGAVmJ3Wevg9Uz C4hL3HoynwnibgGJJXvOM0PYohIvH/9jhbAVJZadOMkGUa8jsWD3JyhbW2LZwtfMEHsFJU7O fMIygVFsFpKxs5C0zELSMgtJywJGllWMgrkZxQZmhsl5yXpFmbl6eaklmxhBCcVRw2AH4/v3 FocYBTgYlXh4hY8YBwqxJpYVV+YeYpTgYFYS4d0QDhTiTUmsrEotyo8vKs1JLT7E6AoMlYnM UtzJ+cBkl1cSb2xggJujJM4rEigaKCSQDkxM2ampBalFMHOYODhB9nBJiRQD00tqUWJpSUY8 KAnGFwPToFQDI1/vpZ/FD/keenQfnHBvp8MqC7E5AiLbhf/9ifDOaS7ZtC9otlVa9f6+P72O aUwhGndmHuTddOvkKkU/tm67BNcYd2ed23f8wzOlpxeLZd+87n2rcfPczLe+pxnimZ/67LVv 3OhgbD8577Vjv9GBSy/KJy5MamngU8tVOKmXdDv1wrf50a7tSizFGYmGWsxFxYkAQ9LW8GkD AAA= X-Mailman-Approved-At: Mon, 04 Mar 2013 07:21:55 -0800 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 23:18:39 -0000 Cullen I don't fully understand your comment maybe because there are several gramma= tical or typing errors in the first two sentences. Are you saying that in your view the instance ID being sent in a register re= quest to a cellular service provider is an issue? The IMEI is already transmitted to the cellular carriers from every GSM, UMT= S and LTE mobile phone using the existing technology and this has been the c= ase since the beginning of GSM (since about 1992). Also in CDMA the MEID (mo= bile Equipment ID) is sent to the CDMA network carriers in every CDMA networ= k. OR are you suggesting that we are sending the instance ID to other users - t= his we are NOT doing. Andrew -----Original Message----- From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] Sent: Saturday, March 02, 2013 6:34 PM To: Andrew Allen Cc: Tom Taylor; Gonzalo Camarillo; dispatch@ietf.org list Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted But the instance ID is in a register sent to trusted providers that know the= users name, credentials etc and can be send in an encrypted channel. This i= s a bit different it that it goes to other users. The analysis is not at the= same. On Jan 19, 2013, at 11:31 AM, Andrew Allen wrote: > Cullen > > To clarify these comments I think are your comments not Tom Taylor's (Tom= simply forwarded my original post as it was rejected due to attached diff f= iles). > > Where does it state in RFC 5626 or anywhere else that an instance ID can b= e changed by the user? > > In fact RFC 5626 states the opposite: > > 3.1. Summary of Mechanism > Each UA has a unique instance-id that stays the same for this UA even= if the UA reboots or is power cycled. > > And > > 4.1. Instance ID Creation > > Each UA MUST have an Instance Identifier Uniform Resource Name (URN) [= RFC2141] that uniquely identifies the device. Usage of a URN > provides a persistent and unique name for the UA instance. It also pro= vides an easy way to guarantee uniqueness within the AOR. This > URN MUST be persistent across power cycles of the device. > > So the instance ID is persistent (RFC 5626 wording) and does not change an= d is not changeable by the user. Whether the instance ID is a UUID or IMEI t= his does not change. > > If an Instance ID containing a UUID is provided in a SIP request or respon= se to another party then it can be stored as the instance ID of a device bel= onging to that user if their identity is known. Then if the same instance ID= is provided again in a SIP request when the originating user requests anony= mity then that user can potentially be identified by correlation with the st= ored instance ID. > > If I call you and your device rings and in the response I receive the inst= ance ID I can potentially learn the Instance ID of the specific device even= if it is a UUID. > > This is the same regardless of whether the instance ID is a UUID or IMEI.= In 3GPP usage the instance ID is never supplied to the far end party except= for the case of emergency calls where the far end is a PSAP. > > RFC 5626 does not seem overly concerned about this privacy issue as it has= a very weak statement - prefer to omit is a far lower strength than MUST NO= T or SHOULD NOT. > > The only thing it states about it is: > > 4.1. Instance ID Creation > > One case where a UA could prefer to omit the "sip.instance" media featur= e tag is when it is making an anonymous request or some other privacy conce= rn > requires that the UA not reveal its identity. > > 3GPP procedures and draft-allen-dispatch-imei-urn-as-instanceid protect re= velation of the Instance ID far more than is required by RFC 5626. > > Andrew > > -----Original Messsage----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beha= lf Of Cullen Jennings (fluffy) > Sent: Saturday, January 19, 2013 11:49 AM > To: Tom Taylor; Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and= , draft-allen-dispatch-imei-urn-as-instanceid submitted > > > On Nov 20, 2012, at 10:16 AM, Tom Taylor wrote= : > >> Those that think privacy issues are insufficiently addressed need to expl= ain why the IMEI is of significantly greater concern in terms of revealing p= rivacy than the UUID when used as an instance ID. > > That has been explained in detail multiple times. For one thing, the user= can't change the IMEI. For a second thing, it can be directly mapped to a s= pecific user in many cases. > >> >> In our view the security concerns raised have now been sufficiently addre= ssed in the drafts and to a much higher bar than that of UUID in RFC 5626. > > I strongly disagree. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately 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. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- 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. From sergio.garcia.murillo@gmail.com Mon Mar 4 03:46:29 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AE121F8A52 for ; Mon, 4 Mar 2013 03:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.878 X-Spam-Level: ** X-Spam-Status: No, score=2.878 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, RCVD_IN_PBL=0.905] 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 nibOTsIQGdHY for ; Mon, 4 Mar 2013 03:46:28 -0800 (PST) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3D02C21F8A3E for ; Mon, 4 Mar 2013 03:46:28 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id d1so781744eab.20 for ; Mon, 04 Mar 2013 03:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j2qn2K4wLBydGOeQs6vl6yq0Rq91/JHLYzOvZtUmqzY=; b=bZOVa2BMGnaDeso69E8gV7QnOcuG8CyeNpwHZ9xUhncfdDfrvA7MbGsNJpKtvVDuaa irQE3upqeDF3L2efcjwRre20ZpWHDc92ttc5DFcxHGJeLy/BTR4O5IWeIBi5SyifyNum 4bTLzxhTx1NI21Yd0DMhZLWPxSzFVTMXj660FpHpPTin9aMZnnfggnYz/sCdlJOgXp0d MGL9x2uH54Cflf2z+Da2F0JpuDztwn+5Fc9e4THHLxDZBIjQwA94Jhxib2OiQMPc2/id Cel+PMWEewAqSbT26FiCuSkDmDV1vJgJ9HTbm2DHjv6gG5/GwslzszpNwI15vfRZXKki bmvA== X-Received: by 10.14.193.134 with SMTP id k6mr58414205een.37.1362397587181; Mon, 04 Mar 2013 03:46:27 -0800 (PST) Received: from [192.168.1.49] (190.Red-95-122-190.staticIP.rima-tde.net. [95.122.190.190]) by mx.google.com with ESMTPS id d47sm31616411eem.9.2013.03.04.03.46.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 03:46:26 -0800 (PST) Message-ID: <51348999.1000506@gmail.com> Date: Mon, 04 Mar 2013 12:46:33 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: stephane.cazeaux@orange.com References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 04 Mar 2013 07:21:55 -0800 Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 11:46:29 -0000 Hi all, I am interested in this topic to implement it in our MCU, so I can provide some real life feedback: http://www.medooze.com/products/mcu.aspx From my point of view, while the datachannels provides natural solutions for some of the issues of bfcp over websockets, implementing support for datachannels is an overkill when we just want to use bcfp. Also, there are quite a lot of clients not supporting bcfp natively, so we would like to provide those clients an alternative http interface to be able to provide the bcfp functionalities. In that scenario, datachannels will not be the best choice. So, as in our case, we will be implementing bcfp over websockets in any case to support this html interface, it would be great to be able to reuse the same implementation for webrtc clients (i.e exchanging the set up information in the sdp), and avoid the costs of implementing datachannels at all. Also, as a side discussion, regardless of the transport chosen, I don't see managing binary messages in the browser is something natural, if possible, it would be a good idea to add support for other serialization formats for bcfp messages more usable in browsers (i.e. json or xml). Best regards Sergio El 28/02/2013 13:09, Victor Pascual Avila escribió: > ---------- Forwarded message ---------- > From: > Date: Sun, Feb 24, 2013 at 10:28 AM > Subject: Re: [dispatch] FW: New Version Notification for > draft-pascual-dispatch-bfcp-websocket-00.txt > To: pkyzivat@alum.mit.edu > Cc: dispatch@ietf.org > > > That was my understanding. My point is that on the browser, the data > channel is part of the webrtc stuff. While websocket is to me more > suitable for such browser to server exchange. > Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE > endpoint since, unless I am wrong, a CLUE endpoint will also have to > support bfcp over tcp (or udp) to interwork with legacy ? > > Stéphane. > ________________________________ > De : Paul Kyzivat > Envoyé : 24/02/2013 02:32 > À : CAZEAUX Stephane OLNC/OLPS > Cc : dispatch@ietf.org > > Objet : Re: [dispatch] FW: New Version Notification for > draft-pascual-dispatch-bfcp-websocket-00.txt > > On 2/22/13 11:40 AM, stephane.cazeaux@orange.com wrote: >> Hi Paul, >> >> Having BFCP over data channel would limit the applicability of BFCP to webrtc (other formulation: it would require the webrtc framework to get BFCP in the browser), while we might want to have BFCP protocol in web client outside of webrtc. > I guess I didn't explain myself well enough. > > What I am suggesting is bfcp over the DTLS/SCTP stack that is being used > for RTCWEB data channels, and that the mechanisms used to negotiate the > stream numbers for each direction be compatible with RTCWEB. In this way > a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.g. > C-based) implementation is also possible. > > This is the same direction we are investigating for the clue data channel. > > The term "data channel" here is perhaps overloaded, because it could > mean a real RTCWEB data channel, or something similar for other > environments. Ideally we would just use SCTP terms, but it has no term > for a bidirectional "channel", only unidirectional streams. But this > should end up being formalized in the SDP. > > Thanks, > Paul > >> Stéphane. >> >> -----Message d'origine----- >> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Envoyé : jeudi 21 février 2013 22:32 >> À : dispatch@ietf.org >> Objet : Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt >> >> Victor, >> >> A question for you: >> >> Another possibility is to map bfcp over a data channel as being specified for rtcweb. >> >> If that were done, would it be a suitable alternative to bfcp over websocket? >> >> We are also going to need bfcp support in conjunction with CLUE. >> And CLUE is going to have its own data channel. We are aiming to use an rtcweb-compatible data channel so that we can have rtcweb browser based clue clients. >> >> If bfcp also worked over a data channel, then these multiple uses of data channels could all coexist on a single SCTP association. And they could work the same regardless of whether or not there are web clients. >> >> Thanks, >> Paul >> >> On 2/21/13 12:38 PM, Victor Pascual Avila wrote: >>> Hi all, >>> >>> We have submitted a new Internet draft to describe the WebSocket >>> Protocol as a Transport for the Binary Floor Control Protocol (BFCP). >>> We are looking forward to your review comments. >>> >>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>> >>> Best regards, >>> -Victor >>> >>> >>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" >>> >>> wrote: >>> >>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt >>>> has been successfully submitted by Victor Pascual and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-pascual-dispatch-bfcp-websocket >>>> Revision: 00 >>>> Title: The WebSocket Protocol as a Transport for the Binary Floor >>>> Control Protocol (BFCP) >>>> Creation date: 2013-02-15 >>>> Group: Individual Submission >>>> Number of pages: 9 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-webso >>>> cket- >>>> 00.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>>> >>>> >>>> Abstract: >>>> The WebSocket protocol enables two-way realtime communication between >>>> clients and servers. This document specifies a new WebSocket sub- >>>> protocol as a reliable transport mechanism between Binary Floor >>>> Control Protocol (BFCP) entities to enable usage of BFCP in new >>>> scenarios. This document normatively updates >>>> [I-D.draft-ietf-bfcpbis-rfc4582bis] and >>>> [I-D.draft-ietf-bfcpbis-rfc4583bis] >>>> >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> _______________________________________________ >>> 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 worley@shell01.TheWorld.com Mon Mar 4 08:39:08 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9056D21F8CB4 for ; Mon, 4 Mar 2013 08:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 Vks-0CDDkhIO for ; Mon, 4 Mar 2013 08:39:04 -0800 (PST) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD0D21F8CA0 for ; Mon, 4 Mar 2013 08:39:04 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r24GcjOu014177 for ; Mon, 4 Mar 2013 11:38:47 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r24GciDj3074746 for ; Mon, 4 Mar 2013 11:38:44 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r24Gcgit3074593; Mon, 4 Mar 2013 11:38:42 -0500 (EST) Date: Mon, 4 Mar 2013 11:38:42 -0500 (EST) Message-Id: <201303041638.r24Gcgit3074593@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: (fluffy@cisco.com) References: <51102D21.10503@stpeter.im> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:39:08 -0000 > From: "Cullen Jennings (fluffy)" > > PS - you might want consider the "Call-Info" header - it would be > very cool to the have HTTP URL in that pointed at the JSON vCard for > the user. > > See http://tools.ietf.org/html/rfc3261#section-20.9 Ah, yes, that's a good place to carry additional URLs. It's already been used to support call-completion. Dale From mary.ietf.barnes@gmail.com Mon Mar 4 09:42:11 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D0521F8D59 for ; Mon, 4 Mar 2013 09:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.699 X-Spam-Level: X-Spam-Status: No, score=-103.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 HFZjT+P-2gYj for ; Mon, 4 Mar 2013 09:42:10 -0800 (PST) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4063121F8D2F for ; Mon, 4 Mar 2013 09:42:10 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id cz11so4005925qeb.40 for ; Mon, 04 Mar 2013 09:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=c0L3+7BhFltYqXhk1okRdx50pC6kbKBiqJh8KJXac3g=; b=r6zRPGYbpsjnI6bwPJtdzskQ13EEW8NDDhhsNg4Qty+KBp2HP1MLXEwGo2Xa1Rqd0l BpFiy8ewOJnazsKD91GvR9zp4idMECY739Ubg+bwdar57t7uOIeiHFdLhOsSapuhkFCq AeMm2+EGrNiZIhLvn48nJrvmRSehI832b+PuPixU1qewFZhS7gf8ylB8IbJ+eAPTxgTe 7MoKAkyAfFHcYdHOa+X6MoGpIV5Yv06V8gnxtZRVJOj2OWawBmdd8MMJ+qZ9asodHNL8 rmzQGm06VKe7nJ53na8O4ONDqDwEEbUYxAD7+98UyOi9PP3aqLuMbxGQYIQHNHAD4ZgP 7qLw== MIME-Version: 1.0 X-Received: by 10.224.27.136 with SMTP id i8mr35576609qac.63.1362418929681; Mon, 04 Mar 2013 09:42:09 -0800 (PST) Received: by 10.49.24.130 with HTTP; Mon, 4 Mar 2013 09:42:09 -0800 (PST) In-Reply-To: <513429DD.9010606@alum.mit.edu> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <513429DD.9010606@alum.mit.edu> Date: Mon, 4 Mar 2013 11:42:09 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Cullen Jennings \(fluffy\)" , "dispatch@ietf.org" , "stephane.cazeaux@orange.com" Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:42:11 -0000 On Sun, Mar 3, 2013 at 10:58 PM, Paul Kyzivat wrote= : > I didn't mean to suggest that there is any interest in doing this in > bfcpbis, or that thre should be. I have been inquiring around a bit just = to > sense if there is any sort of interest. And at the same time wantching th= ese > various one-off activities re websockets. > > I agree that dispatch is a likely place to start discussing this. > And I think it may be best to start discussing it in general rather than > treating each case independently. [MB] Yes - that's exactly what we need to do. The ADs suggested doing this on the RAI area mailing list. But, there are far less people subscribed to that list than this one (260 vs 444). I'll start a new thread on the general topic. [/MB] > > It is probably premature, and too late, to do anything formal about this = in > Orlando. But we might want to talk about it informally, over beer. > > Thanks, > Paul > > > On 3/3/13 7:32 PM, DRAGE, Keith (Keith) wrote: >> >> At the moment these things are out of scope of BFCPBIS as the charter as >> currently worded would prevent this. >> >> But I agree that we do still need a proper discussion of what are the >> correct mechanisms going forward. >> >> I'd note at the moment, and from my perspective, that in terms of public >> visible support there is not enough momentum for any of the options goin= g >> forward - that I guess is partly because noone has called for it, but I >> certainly don't want any of the options allocated to BFCPBIS and find th= at >> noone is interested in reviewing the documents. >> >> At the moment the ADs have indicated the DISPATCH list as the consensus >> building forum for identifying this. That may change, but that is where = the >> discussion needs to be for now. >> >> Keith >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Cullen Jennings (fluffy) >>> Sent: 02 March 2013 23:34 >>> To: Paul Kyzivat >>> Cc: dispatch@ietf.org; stephane.cazeaux@orange.com >>> Subject: Re: [dispatch] Remapping existing protocols for web usage: >>> websockets or data channels? >>> >>> >>> Part of my hope was that if all these things were on the BFCP list, we >>> could come to some sanity about what the optimal number of options are. >>> >>> >>> On Feb 24, 2013, at 3:43 PM, Paul Kyzivat wrote= : >>> >>>> On 2/24/13 5:28 PM, stephane.cazeaux@orange.com wrote: >>>>> >>>>> That was my understanding. My point is that on the browser, the data >>>>> channel is part of the webrtc stuff. While websocket is to me more >>>>> suitable for such browser to server exchange. >>>>> Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE >>>>> endpoint since, unless I am wrong, a CLUE endpoint will also have to >>>>> support bfcp over tcp (or udp) to interwork with legacy ? >>>> >>>> >>>> First, AFAIK there are currently no plans to put bfcp over a data >>> >>> channel, but I think there should be. >>>> >>>> >>>> My reason is because that is a mechanism that could be supported by a = an >>> >>> RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint >>> may >>> still need to support bfcp over tcp or udp for legacy interworking. >>>> >>>> >>>> It would also be possible for an RTCWEB clue client to use bfcp over a >>> >>> websocket. >>>> >>>> >>>> The question is: how many of these alternatives do we want to define a= nd >>> >>> then ask people to support in their products. The more alternatives we >>> have the less likely we are to get interoperability. >>>> >>>> >>>> We have now started down the path of remapping existing protocols (fir= st >>> >>> SIP, then MSRP, now maybe BFCP) over websockets. Meanwhile RTCWEB is >>> defining data channels over SCTP and and CLUE is tentatively planning t= o >>> put its protocol over that. So maybe we had better have a discussion of >>> where we are trying to go, and if what we are doing will get us to a go= od >>> place. >>>> >>>> >>>> Thanks, >>>> Paul >>>> >>>>> St=E9phane. >>>>> ---------------------------------------------------------------------= -- >>> >>> - >>>>> >>>>> De : Paul Kyzivat >>>>> Envoy=E9 : 24/02/2013 02:32 >>>>> =C0 : CAZEAUX Stephane OLNC/OLPS >>>>> Cc : dispatch@ietf.org >>>>> Objet : Re: [dispatch] FW: New Version Notification for >>>>> draft-pascual-dispatch-bfcp-websocket-00.txt >>>>> >>>>> On 2/22/13 11:40 AM, stephane.cazeaux@orange.com wrote: >>>>>> >>>>>> Hi Paul, >>>>>> >>>>>> Having BFCP over data channel would limit the applicability of BFCP = to >>> >>> webrtc (other formulation: it would require the webrtc framework to get >>> BFCP in the browser), while we might want to have BFCP protocol in web >>> client outside of webrtc. >>>>> >>>>> >>>>> I guess I didn't explain myself well enough. >>>>> >>>>> What I am suggesting is bfcp over the DTLS/SCTP stack that is being >>> >>> used >>>>> >>>>> for RTCWEB data channels, and that the mechanisms used to negotiate t= he >>>>> stream numbers for each direction be compatible with RTCWEB. In this >>> >>> way >>>>> >>>>> a true RTCWEB browser client can be implemented, but a non-RTCWEB (e.= g. >>>>> C-based) implementation is also possible. >>>>> >>>>> This is the same direction we are investigating for the clue data >>> >>> channel. >>>>> >>>>> >>>>> The term "data channel" here is perhaps overloaded, because it could >>>>> mean a real RTCWEB data channel, or something similar for other >>>>> environments. Ideally we would just use SCTP terms, but it has no ter= m >>>>> for a bidirectional "channel", only unidirectional streams. But this >>>>> should end up being formalized in the SDP. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> St=E9phane. >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>> Envoy=E9 : jeudi 21 f=E9vrier 2013 22:32 >>>>>> =C0 : dispatch@ietf.org >>>>>> Objet : Re: [dispatch] FW: New Version Notification for draft-pascua= l- >>> >>> dispatch-bfcp-websocket-00.txt >>>>>> >>>>>> >>>>>> Victor, >>>>>> >>>>>> A question for you: >>>>>> >>>>>> Another possibility is to map bfcp over a data channel as being >>> >>> specified for rtcweb. >>>>>> >>>>>> >>>>>> If that were done, would it be a suitable alternative to bfcp over >>> >>> websocket? >>>>>> >>>>>> >>>>>> We are also going to need bfcp support in conjunction with CLUE. >>>>>> And CLUE is going to have its own data channel. We are aiming to use >>> >>> an rtcweb-compatible data channel so that we can have rtcweb browser >>> based >>> clue clients. >>>>>> >>>>>> >>>>>> If bfcp also worked over a data channel, then these multiple uses of >>> >>> data channels could all coexist on a single SCTP association. And they >>> could work the same regardless of whether or not there are web clients. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 2/21/13 12:38 PM, Victor Pascual Avila wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> We have submitted a new Internet draft to describe the WebSocket >>>>>>> Protocol as a Transport for the Binary Floor Control Protocol (BFCP= ). >>>>>>> We are looking forward to your review comments. >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>>>>>> >>>>>>> Best regards, >>>>>>> -Victor >>>>>>> >>>>>>> >>>>>>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt >>>>>>>> has been successfully submitted by Victor Pascual and posted to th= e >>>>>>>> IETF repository. >>>>>>>> >>>>>>>> Filename: draft-pascual-dispatch-bfcp-websocket >>>>>>>> Revision: 00 >>>>>>>> Title: The WebSocket Protocol as a Transport for the Bina= ry >>> >>> Floor >>>>>>>> >>>>>>>> Control Protocol (BFCP) >>>>>>>> Creation date: 2013-02-15 >>>>>>>> Group: Individual Submission >>>>>>>> Number of pages: 9 >>>>>>>> URL: >>>>>>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp- >>> >>> webso >>>>>>>> >>>>>>>> cket- >>>>>>>> 00.txt >>>>>>>> Status: >>>>>>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp- >>> >>> websocket >>>>>>>> >>>>>>>> Htmlized: >>>>>>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-0= 0 >>>>>>>> >>>>>>>> >>>>>>>> Abstract: >>>>>>>> The WebSocket protocol enables two-way realtime communication >>> >>> between >>>>>>>> >>>>>>>> clients and servers. This document specifies a new WebSocket >>> >>> sub- >>>>>>>> >>>>>>>> protocol as a reliable transport mechanism between Binary Floo= r >>>>>>>> Control Protocol (BFCP) entities to enable usage of BFCP in ne= w >>>>>>>> scenarios. This document normatively updates >>>>>>>> [I-D.draft-ietf-bfcpbis-rfc4582bis] and >>>>>>>> [I-D.draft-ietf-bfcpbis-rfc4583bis] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The IETF Secretariat >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >> >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Mon Mar 4 09:42:57 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B420721F8D56 for ; Mon, 4 Mar 2013 09:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.6 X-Spam-Level: X-Spam-Status: No, score=-103.6 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 gttq7XSaPy7Z for ; Mon, 4 Mar 2013 09:42:56 -0800 (PST) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7CABB21F8D2F for ; Mon, 4 Mar 2013 09:42:56 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id u28so875016qcs.8 for ; Mon, 04 Mar 2013 09:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=L8nYavvBe8fFLpr/6PnGHjWM+fG04jbDIGt3amTUGT0=; b=S8raSEkAoQFhSMWXkTvFKntLyG4B/uM3cDvot3p1YKY5OCmj2z0fbQR/qWZlkYFfWN 9C1rMf9VSVOl76rknFl7KCFpbS19j4uA3QyGeZ6HdPLW504NEHBR2neBcjYes4i1vlHn VP8MII7QuZohcUVk8pWc+Q5ucB1SOuNJzNGyqnNpeegOqCgzyUnvwsJ4CYe9h+2ZWsuv owQrBEDn2CW89yMG1rbGq1+3+57WepARAIlDPWudswlSBrANw2V3cehqUYm9Wl81AN37 nUic2lvXZxB7vztc67Vzvwe7/+wVt4JrD6uQDFZTmG5n+0wOGKpmNrAKICJWfP8DdWBM pCKA== MIME-Version: 1.0 X-Received: by 10.224.106.201 with SMTP id y9mr35124071qao.3.1362418975893; Mon, 04 Mar 2013 09:42:55 -0800 (PST) Received: by 10.49.24.130 with HTTP; Mon, 4 Mar 2013 09:42:55 -0800 (PST) In-Reply-To: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <513429DD.9010606@alum.mit.edu> Date: Mon, 4 Mar 2013 11:42:55 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Cullen Jennings \(fluffy\)" , "dispatch@ietf.org" , "stephane.cazeaux@orange.com" Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:42:57 -0000 I just realized the title of this thread is general (and not unique to bfcpbis despite the content). So, I believe we can have the general discuss here. On Mon, Mar 4, 2013 at 11:42 AM, Mary Barnes w= rote: > On Sun, Mar 3, 2013 at 10:58 PM, Paul Kyzivat wro= te: >> I didn't mean to suggest that there is any interest in doing this in >> bfcpbis, or that thre should be. I have been inquiring around a bit just= to >> sense if there is any sort of interest. And at the same time wantching t= hese >> various one-off activities re websockets. >> >> I agree that dispatch is a likely place to start discussing this. >> And I think it may be best to start discussing it in general rather than >> treating each case independently. > [MB] Yes - that's exactly what we need to do. The ADs suggested doing > this on the RAI area mailing list. But, there are far less people > subscribed to that list than this one (260 vs 444). I'll start a new > thread on the general topic. [/MB] >> >> It is probably premature, and too late, to do anything formal about this= in >> Orlando. But we might want to talk about it informally, over beer. >> >> Thanks, >> Paul >> >> >> On 3/3/13 7:32 PM, DRAGE, Keith (Keith) wrote: >>> >>> At the moment these things are out of scope of BFCPBIS as the charter a= s >>> currently worded would prevent this. >>> >>> But I agree that we do still need a proper discussion of what are the >>> correct mechanisms going forward. >>> >>> I'd note at the moment, and from my perspective, that in terms of publi= c >>> visible support there is not enough momentum for any of the options goi= ng >>> forward - that I guess is partly because noone has called for it, but I >>> certainly don't want any of the options allocated to BFCPBIS and find t= hat >>> noone is interested in reviewing the documents. >>> >>> At the moment the ADs have indicated the DISPATCH list as the consensus >>> building forum for identifying this. That may change, but that is where= the >>> discussion needs to be for now. >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Cullen Jennings (fluffy) >>>> Sent: 02 March 2013 23:34 >>>> To: Paul Kyzivat >>>> Cc: dispatch@ietf.org; stephane.cazeaux@orange.com >>>> Subject: Re: [dispatch] Remapping existing protocols for web usage: >>>> websockets or data channels? >>>> >>>> >>>> Part of my hope was that if all these things were on the BFCP list, w= e >>>> could come to some sanity about what the optimal number of options are= . >>>> >>>> >>>> On Feb 24, 2013, at 3:43 PM, Paul Kyzivat wrot= e: >>>> >>>>> On 2/24/13 5:28 PM, stephane.cazeaux@orange.com wrote: >>>>>> >>>>>> That was my understanding. My point is that on the browser, the data >>>>>> channel is part of the webrtc stuff. While websocket is to me more >>>>>> suitable for such browser to server exchange. >>>>>> Btw, what is the rationale of having bfcp over sctp/dtls on a CLUE >>>>>> endpoint since, unless I am wrong, a CLUE endpoint will also have to >>>>>> support bfcp over tcp (or udp) to interwork with legacy ? >>>>> >>>>> >>>>> First, AFAIK there are currently no plans to put bfcp over a data >>>> >>>> channel, but I think there should be. >>>>> >>>>> >>>>> My reason is because that is a mechanism that could be supported by a= an >>>> >>>> RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint >>>> may >>>> still need to support bfcp over tcp or udp for legacy interworking. >>>>> >>>>> >>>>> It would also be possible for an RTCWEB clue client to use bfcp over = a >>>> >>>> websocket. >>>>> >>>>> >>>>> The question is: how many of these alternatives do we want to define = and >>>> >>>> then ask people to support in their products. The more alternatives we >>>> have the less likely we are to get interoperability. >>>>> >>>>> >>>>> We have now started down the path of remapping existing protocols (fi= rst >>>> >>>> SIP, then MSRP, now maybe BFCP) over websockets. Meanwhile RTCWEB is >>>> defining data channels over SCTP and and CLUE is tentatively planning = to >>>> put its protocol over that. So maybe we had better have a discussion o= f >>>> where we are trying to go, and if what we are doing will get us to a g= ood >>>> place. >>>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> St=E9phane. >>>>>> --------------------------------------------------------------------= --- >>>> >>>> - >>>>>> >>>>>> De : Paul Kyzivat >>>>>> Envoy=E9 : 24/02/2013 02:32 >>>>>> =C0 : CAZEAUX Stephane OLNC/OLPS >>>>>> Cc : dispatch@ietf.org >>>>>> Objet : Re: [dispatch] FW: New Version Notification for >>>>>> draft-pascual-dispatch-bfcp-websocket-00.txt >>>>>> >>>>>> On 2/22/13 11:40 AM, stephane.cazeaux@orange.com wrote: >>>>>>> >>>>>>> Hi Paul, >>>>>>> >>>>>>> Having BFCP over data channel would limit the applicability of BFCP= to >>>> >>>> webrtc (other formulation: it would require the webrtc framework to ge= t >>>> BFCP in the browser), while we might want to have BFCP protocol in web >>>> client outside of webrtc. >>>>>> >>>>>> >>>>>> I guess I didn't explain myself well enough. >>>>>> >>>>>> What I am suggesting is bfcp over the DTLS/SCTP stack that is being >>>> >>>> used >>>>>> >>>>>> for RTCWEB data channels, and that the mechanisms used to negotiate = the >>>>>> stream numbers for each direction be compatible with RTCWEB. In this >>>> >>>> way >>>>>> >>>>>> a true RTCWEB browser client can be implemented, but a non-RTCWEB (e= .g. >>>>>> C-based) implementation is also possible. >>>>>> >>>>>> This is the same direction we are investigating for the clue data >>>> >>>> channel. >>>>>> >>>>>> >>>>>> The term "data channel" here is perhaps overloaded, because it could >>>>>> mean a real RTCWEB data channel, or something similar for other >>>>>> environments. Ideally we would just use SCTP terms, but it has no te= rm >>>>>> for a bidirectional "channel", only unidirectional streams. But this >>>>>> should end up being formalized in the SDP. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> St=E9phane. >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>> Envoy=E9 : jeudi 21 f=E9vrier 2013 22:32 >>>>>>> =C0 : dispatch@ietf.org >>>>>>> Objet : Re: [dispatch] FW: New Version Notification for draft-pascu= al- >>>> >>>> dispatch-bfcp-websocket-00.txt >>>>>>> >>>>>>> >>>>>>> Victor, >>>>>>> >>>>>>> A question for you: >>>>>>> >>>>>>> Another possibility is to map bfcp over a data channel as being >>>> >>>> specified for rtcweb. >>>>>>> >>>>>>> >>>>>>> If that were done, would it be a suitable alternative to bfcp over >>>> >>>> websocket? >>>>>>> >>>>>>> >>>>>>> We are also going to need bfcp support in conjunction with CLUE. >>>>>>> And CLUE is going to have its own data channel. We are aiming to us= e >>>> >>>> an rtcweb-compatible data channel so that we can have rtcweb browser >>>> based >>>> clue clients. >>>>>>> >>>>>>> >>>>>>> If bfcp also worked over a data channel, then these multiple uses o= f >>>> >>>> data channels could all coexist on a single SCTP association. And they >>>> could work the same regardless of whether or not there are web clients= . >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> On 2/21/13 12:38 PM, Victor Pascual Avila wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> We have submitted a new Internet draft to describe the WebSocket >>>>>>>> Protocol as a Transport for the Binary Floor Control Protocol (BFC= P). >>>>>>>> We are looking forward to your review comments. >>>>>>>> >>>>>>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-0= 0 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> -Victor >>>>>>>> >>>>>>>> >>>>>>>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.tx= t >>>>>>>>> has been successfully submitted by Victor Pascual and posted to t= he >>>>>>>>> IETF repository. >>>>>>>>> >>>>>>>>> Filename: draft-pascual-dispatch-bfcp-websocket >>>>>>>>> Revision: 00 >>>>>>>>> Title: The WebSocket Protocol as a Transport for the Bin= ary >>>> >>>> Floor >>>>>>>>> >>>>>>>>> Control Protocol (BFCP) >>>>>>>>> Creation date: 2013-02-15 >>>>>>>>> Group: Individual Submission >>>>>>>>> Number of pages: 9 >>>>>>>>> URL: >>>>>>>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp- >>>> >>>> webso >>>>>>>>> >>>>>>>>> cket- >>>>>>>>> 00.txt >>>>>>>>> Status: >>>>>>>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp- >>>> >>>> websocket >>>>>>>>> >>>>>>>>> Htmlized: >>>>>>>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-= 00 >>>>>>>>> >>>>>>>>> >>>>>>>>> Abstract: >>>>>>>>> The WebSocket protocol enables two-way realtime communication >>>> >>>> between >>>>>>>>> >>>>>>>>> clients and servers. This document specifies a new WebSocket >>>> >>>> sub- >>>>>>>>> >>>>>>>>> protocol as a reliable transport mechanism between Binary Flo= or >>>>>>>>> Control Protocol (BFCP) entities to enable usage of BFCP in n= ew >>>>>>>>> scenarios. This document normatively updates >>>>>>>>> [I-D.draft-ietf-bfcpbis-rfc4582bis] and >>>>>>>>> [I-D.draft-ietf-bfcpbis-rfc4583bis] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The IETF Secretariat >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From stpeter@stpeter.im Mon Mar 4 11:03:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5CE21F86A6 for ; Mon, 4 Mar 2013 11:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 6fXZHTZVB2Zq for ; Mon, 4 Mar 2013 11:03:48 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 56BE921F8C87 for ; Mon, 4 Mar 2013 11:03:48 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3573B4004E; Mon, 4 Mar 2013 12:11:55 -0700 (MST) Message-ID: <5134F00F.9030301@stpeter.im> Date: Mon, 04 Mar 2013 12:03:43 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Olle E. Johansson" References: <51102D21.10503@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Cullen Jennings \(fluffy\)" , "dispatch@ietf.org" , Emil Ivov Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 19:03:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/4/13 1:51 AM, Olle E. Johansson wrote: > > 3 mar 2013 kl. 14:12 skrev "Cullen Jennings (fluffy)" > : > >> >> If you don't want to do the vcard but just want the xmpp address >> directly, I'd probably suggest something like >> >> Call-Info: ;purpose=impp >> >> To just indicate that the URL provided the IM and Presence >> service for that user >> >> RFC 3261 section 20.9 says that the IANA section of 3261 will >> define how to add a new purpose but as far as I can tell it does >> not. However, the IANA SIP registry for the URI purpose at >> >> http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-13 >> >> >> is just spec required so I think think you might be able to trivial add a "impp" purpose. > Shouldn't the purposes in RFC 3261 be added to that registry too? Hej Olle, Yeah, I went searching for those in the registry yesterday and couldn't find them. It sounds like someone needs to register them. RFC 3261 says: The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Actually, I think "icon", "info", and "card" are values of the "purpose" parameter, not parameters in themselves, right? I find the Header Field Parameters and Parameter Values registry a bit confusing: https://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-12 Some of those header fields have predefined values. It's not clear to me if those values need to be registered. Section 20.9 of RFC 3261 says they do, but Section 27 doesn't say how. (When oh when is someone going to work on 3261bis? ;-) Olle/Emil, how about you and I take this up with IANA folks during their office hours in Orlando? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNPAPAAoJEOoGpJErxa2pgvwP/jnZrFSx3H82349715qd6jN2 /rWF+VLF73tEBHX/ssBaBr4Kwu/RJ+oYK6+jNYbpiq9cmUEsSLjOJOY0frygUHej rE/uV5CtXwkn453yWX2ocEUHXI5bnrgENXxqPy2YITXETogf+Ybbs00IrvneMzdL FVnxYXFYVWKmKIPbgrGxVD4xDH030yQyxzewUDm6TrF/R3LoSlwULYxle4jfgyYm 3bVh64DBsQto39MvtY32abHP1WF1Iav76o7GT0aBb3A09Xv+NkmyRk3EpSbUpj0K 0zksaLV3bXivBKKjjC3tV9QiDPCD5bYfqQh5UyiJ+PVYOxGFOt191AfH+8oqyowV cpMXDWPeewRoUaskuTyXsPgL5TiCoeBzOgDF+SnLHk5Uq78tjyrH5YJOHD2Zd1AS LKn0Xqnb2yZdeFqCEoBAZfAo5W64dj5FF+03+98NxJ4IKFHBob6x/NpeSc3EAvit iJxzki6l+MpdK2yd6SbvaMPf2UlqOXBpPuDmxM1SlmgJbWFV3BpvoOjGGHGQcz+v 3W13GAv4HXp3LtpgCduAUtBmDsMxydPwy+Zsm2bhkr0XChK9VX2HqbktaU2qOHU5 QOLqLh5RWFcdK4WVkEtqoNvwHVFq53zC25Ujnq/niBUBm7lvHpuO0E029Gu0AtMY WnUZHMGNtbAV+KlfHip2 =7auh -----END PGP SIGNATURE----- From rifatyu@avaya.com Mon Mar 4 11:25:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94F721F8D08 for ; Mon, 4 Mar 2013 11:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qRAec3rg9782 for ; Mon, 4 Mar 2013 11:25:22 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1027721F8976 for ; Mon, 4 Mar 2013 11:25:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAP0QA1HGmAcF/2dsb2JhbAA8CYJru2cWc4IeAQEBAQMBAQEPKDQLDAQCAQgNBAQBAQEKFAkHJwsUCQgCBAENBQgBGYdtAQuhWJx0jQuDU2EDnBqKO4J3giQ X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208";a="345916860" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Mar 2013 14:29:11 -0500 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Mar 2013 14:24:36 -0500 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Mon, 4 Mar 2013 14:25:17 -0500 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Peter Saint-Andre , "Olle E. Johansson" Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity Thread-Index: AQHOGQr9SIPFU2v3v02dtExy7g61EJiV51LA Date: Mon, 4 Mar 2013 19:25:16 +0000 Message-ID: References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> In-Reply-To: <5134F00F.9030301@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , "dispatch@ietf.org" , Emil Ivov Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 19:25:26 -0000 Peter, Today, there is no registry for the "purpose" values in the Call-Info heade= r. Mary and I have an open issue around this in the following draft, as we wou= ld like to register a "ccmp" value. https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-indication/?incl= ude_text=3D1 Please, keep us posted on your discussion with IANA on this. Regards, Rifaat > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Peter Saint-Andre > Sent: Monday, March 04, 2013 2:04 PM > To: Olle E. Johansson > Cc: Cullen Jennings (fluffy); dispatch@ietf.org; Emil Ivov > Subject: Re: [dispatch] URI schemes in P-Asserted-Identity >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 3/4/13 1:51 AM, Olle E. Johansson wrote: > > > > 3 mar 2013 kl. 14:12 skrev "Cullen Jennings (fluffy)" > > : > > > >> > >> If you don't want to do the vcard but just want the xmpp address > >> directly, I'd probably suggest something like > >> > >> Call-Info: ;purpose=3Dimpp > >> > >> To just indicate that the URL provided the IM and Presence > >> service for that user > >> > >> RFC 3261 section 20.9 says that the IANA section of 3261 will > >> define how to add a new purpose but as far as I can tell it does > >> not. However, the IANA SIP registry for the URI purpose at > >> > >> http://www.iana.org/assignments/sip-parameters/sip- > parameters.xml#sip-parameters-13 > >> > >> > >> > is just spec required so I think think you might be able to trivial add > a "impp" purpose. > > Shouldn't the purposes in RFC 3261 be added to that registry too? >=20 > Hej Olle, >=20 > Yeah, I went searching for those in the registry yesterday and > couldn't find them. It sounds like someone needs to register them. >=20 > RFC 3261 says: >=20 > The Call-Info header field provides additional information about the > caller or callee, depending on whether it is found in a request or > response. The purpose of the URI is described by the "purpose" > parameter. The "icon" parameter designates an image suitable as an > iconic representation of the caller or callee. The "info" parameter > describes the caller or callee in general, for example, through a > web > page. The "card" parameter provides a business card, for example, > in > vCard [36] or LDIF [37] formats. Additional tokens can be > registered > using IANA and the procedures in Section 27. >=20 > Actually, I think "icon", "info", and "card" are values of the > "purpose" parameter, not parameters in themselves, right? >=20 > I find the Header Field Parameters and Parameter Values registry a bit > confusing: >=20 > https://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip- > parameters-12 >=20 > Some of those header fields have predefined values. It's not clear to > me if those values need to be registered. Section 20.9 of RFC 3261 > says they do, but Section 27 doesn't say how. (When oh when is someone > going to work on 3261bis? ;-) >=20 > Olle/Emil, how about you and I take this up with IANA folks during > their office hours in Orlando? >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQIcBAEBAgAGBQJRNPAPAAoJEOoGpJErxa2pgvwP/jnZrFSx3H82349715qd6jN2 > /rWF+VLF73tEBHX/ssBaBr4Kwu/RJ+oYK6+jNYbpiq9cmUEsSLjOJOY0frygUHej > rE/uV5CtXwkn453yWX2ocEUHXI5bnrgENXxqPy2YITXETogf+Ybbs00IrvneMzdL > FVnxYXFYVWKmKIPbgrGxVD4xDH030yQyxzewUDm6TrF/R3LoSlwULYxle4jfgyYm > 3bVh64DBsQto39MvtY32abHP1WF1Iav76o7GT0aBb3A09Xv+NkmyRk3EpSbUpj0K > 0zksaLV3bXivBKKjjC3tV9QiDPCD5bYfqQh5UyiJ+PVYOxGFOt191AfH+8oqyowV > cpMXDWPeewRoUaskuTyXsPgL5TiCoeBzOgDF+SnLHk5Uq78tjyrH5YJOHD2Zd1AS > LKn0Xqnb2yZdeFqCEoBAZfAo5W64dj5FF+03+98NxJ4IKFHBob6x/NpeSc3EAvit > iJxzki6l+MpdK2yd6SbvaMPf2UlqOXBpPuDmxM1SlmgJbWFV3BpvoOjGGHGQcz+v > 3W13GAv4HXp3LtpgCduAUtBmDsMxydPwy+Zsm2bhkr0XChK9VX2HqbktaU2qOHU5 > QOLqLh5RWFcdK4WVkEtqoNvwHVFq53zC25Ujnq/niBUBm7lvHpuO0E029Gu0AtMY > WnUZHMGNtbAV+KlfHip2 > =3D7auh > -----END PGP SIGNATURE----- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From oej@edvina.net Mon Mar 4 11:56:08 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DB421F8F07 for ; Mon, 4 Mar 2013 11:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 v7UQ1QGV4UAF for ; Mon, 4 Mar 2013 11:56:07 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id F196721F8EF2 for ; Mon, 4 Mar 2013 11:56:06 -0800 (PST) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 2FDCB93DE3C; Mon, 4 Mar 2013 19:55:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <5134F00F.9030301@stpeter.im> Date: Mon, 4 Mar 2013 20:55:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8E8692C3-5139-4B58-AB18-3F4F075B647B@edvina.net> References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) Cc: "Cullen Jennings \(fluffy\)" , Emil Ivov , "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 19:56:08 -0000 4 mar 2013 kl. 20:03 skrev Peter Saint-Andre : > Olle/Emil, how about you and I take this up with IANA folks during > their office hours in Orlando? Sorry, Don't have the resources to go there. WIll be available online most of = the time though. /O= From stpeter@stpeter.im Mon Mar 4 12:21:13 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9821F8D23 for ; Mon, 4 Mar 2013 12:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 9Nopd62vIcD5 for ; Mon, 4 Mar 2013 12:21:12 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C70FD21F8F67 for ; Mon, 4 Mar 2013 12:20:23 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 276184004E; Mon, 4 Mar 2013 13:28:30 -0700 (MST) Message-ID: <51350201.6090507@stpeter.im> Date: Mon, 04 Mar 2013 13:20:17 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Cullen Jennings \(fluffy\)" , Emil Ivov , "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:21:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/4/13 12:25 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Peter, > > Today, there is no registry for the "purpose" values in the > Call-Info header. Mary and I have an open issue around this in the > following draft, as we would like to register a "ccmp" value. > https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-indication/?include_text=1 > > Please, keep us posted on your discussion with IANA on this. Thinking about this further, I realize we might need a new, very short I-D that creates the registry. I think this is something that one of us could write in an hour. I'd be happy to do that before the I-D submission window opens again. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNQIAAAoJEOoGpJErxa2pJDwQAJljt/cq/Lx3L+BRR7O/2BZx 2pTJHA2RT5EhX897dkTvvLPvgXFlSrXw8k3r1zNKqfAe+ZLbUoIxyhvoA2swuKOI qBB+tGZPZ6JyLHgYOKGUXERCsroIhIpjF3bR/BD4yhiwQdJ+A0kzZAJZjl5eMQM5 UgR7am+6jfqrJmlq7K8JBB7KxNunPkDBRpySoxj5qn1xFB3Nvafp038WVvzC2ARE k4PRyUgELKy7L8cXNohq/PbGk7joGE95UtCJH2KXLfVQJCHclPbmUxnUklTKb0r+ EJgX94sGzi4Vx59GsM0K/rPmkPBEtZ8EzPQ0T6/TzL0jquunM39IzVVz6zJALRcT /lBLWk7XkevvWFdtKE4pel/Fp/hTwZgAcuM2//TGRQyLxLn6Xwje+RenTIt9yGtd dNrwW2QTlXmjZ41RWhLvubQXI1DYRLM38VoH6BoaiYk7zMoGpHDeq8077Hhhs907 9ROUY2GGO7gwT599TowaWji/7Rw8p3W87nuNVFXy1Zz6CuHay8GksvHdLtXIT5Kc tBFnqS8rbWIJ1HQrb92E7GTAfYzhDd/CRj7BbaLUCEU2LGqMzfamXcbuJLtkbzzb URrA7b6Y1CVE8vJPeBV+HY0sYru4utf14UHkLNvZiVu5MTzyRE5sGNLNSj2rHVmA r2cfHMCniL0TR7NHJ6GS =H0iU -----END PGP SIGNATURE----- From worley@shell01.TheWorld.com Mon Mar 4 12:22:02 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C141121F8FB2 for ; Mon, 4 Mar 2013 12:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.963 X-Spam-Level: X-Spam-Status: No, score=-2.963 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 VdQ7oWPaF4ga for ; Mon, 4 Mar 2013 12:22:02 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id D05FC21F8FB0 for ; Mon, 4 Mar 2013 12:22:01 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r24KLXfl020137; Mon, 4 Mar 2013 15:21:35 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r24KLXig3073849; Mon, 4 Mar 2013 15:21:33 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r24KLXjF3047185; Mon, 4 Mar 2013 15:21:33 -0500 (EST) Date: Mon, 4 Mar 2013 15:21:33 -0500 (EST) Message-Id: <201303042021.r24KLXjF3047185@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Cullen Jennings (fluffy)" , dispatch@ietf.org In-reply-to: (fluffy@cisco.com) References: <50ABBAD6.9050103@gmail.com> Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:22:02 -0000 > From: "Cullen Jennings (fluffy)" > > But the instance ID is in a register sent to trusted providers that > know the users name, credentials etc and can be send in an encrypted > channel. This is a bit different it that it goes to other users. The > analysis is not at the same. This is a bit awkward to read, but I believe that your intention is: When the instance ID is in a REGISTER, it is sent to trusted providers that know the user's name, credentials, etc. already, and it can be sent in an encrypted channel. This proposal (i.e., draft-allen-dispatch-imei-urn-as-instanceid) is different in that the the GRUU containing the IMEI is sent to other users. The analysis is not the same. Please correct me if I'm wrong. But assuming that I'm correct: Yes, draft-allen-dispatch-imei-urn-as-instanceid results in the IMEI being sent to other users, embedded in the Contact GRUU. And the privacy analysis of that is different from that of a REGISTER. The user that receives the IMEI-containing URI does not have a database mapping the IMEI to the user's name or other data. (Or at least, I don't expect the service providers to make their database available to subscribers.) So the IMEI-containing URI is reduced from a personal identifier to a "constant user fingerprint", an identifier that is associated with just one person, but anyone who wants to make use of that fact has to figure out themselves which person it is. And that is the same as any with other GRUU. If one's phone is using a GRUU, any conversant can record the GRUU and one's name, and use it to identify further calls from one's self. Of course, if the user intends anonymity, the user can cause the UA to obtain a temporary GRUU which is not a constant user fingerprint, as is implied by section 8 of the draft. We've already worked through this problem. Dale From rifatyu@avaya.com Mon Mar 4 13:08:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1AF21F87EA for ; Mon, 4 Mar 2013 13:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2] 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 LLIrDjMarlIc for ; Mon, 4 Mar 2013 13:08:52 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE8F21F8654 for ; Mon, 4 Mar 2013 13:08:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALh+MVHGmAcF/2dsb2JhbAA7CYJmg2m7dQ1zFnOCHwEBAQEDEhFWDAQCAQgNBAQBAQEKHQMCAgIwFAkIAgQOBQgBBRSHcQELpByKK5IYjUwHgRkGIAsHBgOCJDJhA4phhEeIOYR7hT2FFYMIgXI1 X-IronPort-AV: E=Sophos;i="4.84,766,1355115600"; d="txt'?scan'208";a="255331" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Mar 2013 16:08:51 -0500 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Mar 2013 16:08:09 -0500 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Mon, 4 Mar 2013 16:08:50 -0500 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Peter Saint-Andre Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity Thread-Index: AQHOGQr9SIPFU2v3v02dtExy7g61EJiV51LAgABlyID//7iucA== Date: Mon, 4 Mar 2013 21:08:10 +0000 Message-ID: References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51350201.6090507@stpeter.im> In-Reply-To: <51350201.6090507@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: multipart/mixed; boundary="_002_C563F76EA324474CA3722A35154AFDB3139DF35AAZUS1EXMB01glob_" MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , Emil Ivov , "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 21:08:53 -0000 --_002_C563F76EA324474CA3722A35154AFDB3139DF35AAZUS1EXMB01glob_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGV0ZXIsDQoNClRha2UgYSBsb29rIGF0IHRoZSBhdHRhY2hlZCBkb2N1bWVudCBhbmQgbGV0IG1l IGtub3cgaWYgdGhhdCBpcyBnb29kIGVub3VnaCBhcyBhIHN0YXJ0aW5nIHBvaW50Lg0KDQpSZWdh cmRzLA0KIFJpZmFhdA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog UGV0ZXIgU2FpbnQtQW5kcmUgW21haWx0bzpzdHBldGVyQHN0cGV0ZXIuaW1dDQo+IFNlbnQ6IE1v bmRheSwgTWFyY2ggMDQsIDIwMTMgMzoyMCBQTQ0KPiBUbzogU2hla2gtWXVzZWYsIFJpZmFhdCAo UmlmYWF0KQ0KPiBDYzogT2xsZSBFLiBKb2hhbnNzb247IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5 KTsgZGlzcGF0Y2hAaWV0Zi5vcmc7DQo+IEVtaWwgSXZvdg0KPiBTdWJqZWN0OiBSZTogW2Rpc3Bh dGNoXSBVUkkgc2NoZW1lcyBpbiBQLUFzc2VydGVkLUlkZW50aXR5DQo+IA0KPiAtLS0tLUJFR0lO IFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQo+IEhhc2g6IFNIQTENCj4gDQo+IE9uIDMvNC8xMyAx MjoyNSBQTSwgU2hla2gtWXVzZWYsIFJpZmFhdCAoUmlmYWF0KSB3cm90ZToNCj4gPiBQZXRlciwN Cj4gPg0KPiA+IFRvZGF5LCB0aGVyZSBpcyBubyByZWdpc3RyeSBmb3IgdGhlICJwdXJwb3NlIiB2 YWx1ZXMgaW4gdGhlDQo+ID4gQ2FsbC1JbmZvIGhlYWRlci4gTWFyeSBhbmQgSSBoYXZlIGFuIG9w ZW4gaXNzdWUgYXJvdW5kIHRoaXMgaW4gdGhlDQo+ID4gZm9sbG93aW5nIGRyYWZ0LCBhcyB3ZSB3 b3VsZCBsaWtlIHRvIHJlZ2lzdGVyIGEgImNjbXAiIHZhbHVlLg0KPiA+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXl1c2VmLWRpc3BhdGNoLWNjbXAtDQo+IGluZGljYXRp b24vP2luY2x1ZGVfdGV4dD0xDQo+ID4NCj4gPiAgUGxlYXNlLCBrZWVwIHVzIHBvc3RlZCBvbiB5 b3VyIGRpc2N1c3Npb24gd2l0aCBJQU5BIG9uIHRoaXMuDQo+IA0KPiBUaGlua2luZyBhYm91dCB0 aGlzIGZ1cnRoZXIsIEkgcmVhbGl6ZSB3ZSBtaWdodCBuZWVkIGEgbmV3LCB2ZXJ5IHNob3J0DQo+ IEktRCB0aGF0IGNyZWF0ZXMgdGhlIHJlZ2lzdHJ5LiBJIHRoaW5rIHRoaXMgaXMgc29tZXRoaW5n IHRoYXQgb25lIG9mDQo+IHVzIGNvdWxkIHdyaXRlIGluIGFuIGhvdXIuIEknZCBiZSBoYXBweSB0 byBkbyB0aGF0IGJlZm9yZSB0aGUgSS1EDQo+IHN1Ym1pc3Npb24gd2luZG93IG9wZW5zIGFnYWlu Lg0KPiANCj4gUGV0ZXINCj4gDQo+IC0gLS0NCj4gUGV0ZXIgU2FpbnQtQW5kcmUNCj4gaHR0cHM6 Ly9zdHBldGVyLmltLw0KPiANCj4gDQo+IC0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQo+ IFZlcnNpb246IEdudVBHL01hY0dQRzIgdjIuMC4xOCAoRGFyd2luKQ0KPiBDb21tZW50OiBVc2lu ZyBHbnVQRyB3aXRoIFRodW5kZXJiaXJkIC0gaHR0cDovL3d3dy5lbmlnbWFpbC5uZXQvDQo+IA0K PiBpUUljQkFFQkFnQUdCUUpSTlFJQUFBb0pFT29HcEpFcnhhMnBKRHdRQUpsanQvY3EvTHgzTCtC UlI3Ty8yQlp4DQo+IDJwVEpIQTJSVDVFaFg4OTdka1R2dkxQdmdYRmxTclh3OGszcjF6TktxZkFl K1pMYlVvSXh5aHZvQTJzd3VLT0kNCj4gcUJCK3RHWlBaNkp5TEhnWU9LR1VYRVJDc3JvSWhJcGpG M2JSL0JENHloaXdRZEorQTBrelpBSlpqbDVlTVFNNQ0KPiBVZ1I3YW0rNmpmcXJKbWxxN0s4SkJC N0t4TnVuUGtEQlJweVNveGo1cW4xeEZCM052YWZwMDM4V1Z2ekMyQVJFDQo+IGs0UFJ5VWdFTEt5 N0w4Y1hOb2hxL1BiR2s3am9HRTk1VXRDSkgyS1hMZlZRSkNIY2xQYm1VeG5Va2xUS2IwcisNCj4g RUpnWDk0c0d6aTRWeDU5R3NNMEsvclBta1BCRXRaOEV6UFEwVDYvVHpMMGpxdXVuTTM5SXpWVno2 ekpBTFJjVA0KPiAvbEJMV2s3WGtldnZXRmR0S0U0cGVsL0ZwL2hUd1pnQWN1TTIvL1RHUlF5THhM bjZYd2plK1JlblRJdDl5R3RkDQo+IGROcndXMlFUbFhtalo0MVJXaEx2dWJRWEkxRFlSTE0zOFZv SDZCb2FpWWs3ek1vR3BIRGVxODA3N0hoaHM5MDcNCj4gOVJPVVkyR0dPN2d3VDU5OVRvd2FXamkv N1J3OHAzVzg3bnVOVkZYeTFaejZDdUhheThHa3N2SGRMdFhJVDVLYw0KPiB0QkZucVM4cmJXSUox SFFyYjkyRTdHVEFmWXpoRGQvQ1JqN0JiYUxVQ0VVMkxHcU16ZmFtWGNidUpMdGtienpiDQo+IFVS ckE3YjZZMUNWRTh2SlBlQlYrSFkwc1lydTR1dGYxNFVIa0xOdlppVnU1TVR6eVJFNXNHTkxOU2oy ckhWbUENCj4gcjJjZkhNQ25pTDBUUjdOSEo2R1MNCj4gPUgwaVUNCj4gLS0tLS1FTkQgUEdQIFNJ R05BVFVSRS0tLS0tDQo= --_002_C563F76EA324474CA3722A35154AFDB3139DF35AAZUS1EXMB01glob_ Content-Type: text/plain; name="draft-yusef-dispatch-purpose-00.txt" Content-Description: draft-yusef-dispatch-purpose-00.txt Content-Disposition: attachment; filename="draft-yusef-dispatch-purpose-00.txt"; size=5532; creation-date="Mon, 04 Mar 2013 20:42:19 GMT"; modification-date="Mon, 04 Mar 2013 21:03:04 GMT" Content-Transfer-Encoding: base64 IA0KDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDxBdXRob3I+DQpJbnRlbmRlZCBTdGF0dXM6IDxTdGF0dXMsIGUuZy5Q cm9wb3NlZCBTdGFuZGFyZD4gICAgICAgICAgKDxBdXRob3IgT3JnPikNCkV4cGlyZXM6IDxFeHBp cnkgRGF0ZT4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxJc3N1ZSBEYXRl Pg0KDQoNCiAgICAgICAgSUFOQSBSZWdpc3RyeSBmb3IgdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQ cm90b2NvbCAoU0lQKSANCiAgICAgICAgICAgICAgICAgICAgICAgICAgIlB1cnBvc2UiIHBhcmFt ZXRlcg0KICAgICAgICAgICAgICAgICAgICBkcmFmdC15dXNlZi1kaXNwYXRjaC1wdXJwb3NlLTAw DQoNCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IElBTkEgcmVn aXN0cnkgZm9yIHRoZSB2YWx1ZXMgZGVmaW5lZCBmb3INCiAgIHRoZSBTZXNzaW9uIEluaXRpYXRp b24gUHJvdG9jb2wgKFNJUCkgIlB1cnBvc2UiIHBhcmFtZXRlciBvZiB0aGUNCiAgIENhbGwtSW5m byBoZWFkZXIsIHdoaWNoIHVwZGF0ZXMgUkZDIDMyNjEuDQoNCg0KU3RhdHVzIG9mIHRoaXMgTWVt bw0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCB0byBJRVRGIGluIGZ1bGwg Y29uZm9ybWFuY2Ugd2l0aCB0aGUNCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzku DQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVy bmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRz IHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcw0KICAgSW50ZXJuZXQtRHJhZnRzLg0KDQogICBJ bnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRl ZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0 ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8g Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlz dCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvMWlkLWFic3RyYWN0cy5odG1sDQoNCiAgIFRoZSBsaXN0IG9mIEludGVy bmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCg0KDQpDb3B5cmlnaHQgYW5kIExpY2Vuc2UgTm90 aWNlDQoNCiAgIENvcHlyaWdodCAoYykgPHllYXI+IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25z IGlkZW50aWZpZWQgYXMgdGhlDQogICBkb2N1bWVudCBhdXRob3JzLiBBbGwgcmlnaHRzIHJlc2Vy dmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVU RiBUcnVzdCdzIExlZ2FsDQogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRz DQogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24g dGhlIGRhdGUgb2YNCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIFBsZWFzZSByZXZp ZXcgdGhlc2UgZG9jdW1lbnRzDQogDQoNCg0KPEF1dGhvcj4gICAgICAgICAgICAgICAgIEV4cGly ZXMgPEV4cGlyeSBEYXRlPiAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJTlRFUk5FVCBE UkFGVCAgICAgICAgICAgICAgPERvY3VtZW50IFRpdGxlPiAgICAgICAgICAgICAgICA8SXNzdWUg RGF0ZT4NCg0KDQogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5k IHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCiAgIHRvIHRoaXMgZG9jdW1lbnQuIENvZGUgQ29t cG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2lt cGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0K ICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdh cnJhbnR5IGFzDQogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoN Cg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAxICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgICAgMS4xICBUZXJt aW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg Mw0KICAgMiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAzDQogICAzICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDUgIFJlZmVyZW5jZXMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAg ICA1LjEgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAzDQogICAgIDUuMiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KIA0KDQoN CjxBdXRob3I+ICAgICAgICAgICAgICAgICBFeHBpcmVzIDxFeHBpcnkgRGF0ZT4gICAgICAgICAg ICAgICAgICBbUGFnZSAyXQ0KDA0KSU5URVJORVQgRFJBRlQgICAgICAgICAgICAgIDxEb2N1bWVu dCBUaXRsZT4gICAgICAgICAgICAgICAgPElzc3VlIERhdGU+DQoNCg0KMSAgSW50cm9kdWN0aW9u DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBJQU5BIHJlZ2lzdHJ5IGZvciB0aGUg dmFsdWVzIGRlZmluZWQgZm9yDQogICB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChT SVApICJQdXJwb3NlIiBwYXJhbWV0ZXIgb2YgdGhlDQogICBDYWxsLUluZm8gaGVhZGVyLCB3aGlj aCB1cGRhdGVzIFJGQyAzMjYxLiBUaGlzIHBhcmFtZXRlciB3YXMgZGVmaW5lZA0KICAgaW4gUkZD MzI2MSwgc2VjdGlvbiAyMC45IENhbGwtSW5mbywgd2hpY2ggY2xlYXJseSBzdGF0ZXMgdGhhdA0K ICAgYWRkaXRpb25hbCB0b2tlbnMgY2FuIGJlIHJlZ2lzdGVyZWQgd2l0aCBJQU5BLCBidXQgbm8g cmVnaXN0cnkgd2FzDQogICBlc3RhYmxpc2hlZCBmb3IgdGhhdC4NCg0KDQoxLjEgIFRlcm1pbm9s b2d5DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAi U0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1F TkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8g YmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4NCg0KDQoN CjIgIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBjcmVhdGVzIGEgbmV3 IHJlZ2lzdHJ5LCAiUHVycG9zZSBQYXJhbWV0ZXIgVmFsdWVzLiIgVGhlDQogICBmb3JtYXQgYW5k IGluaXRpYWwgdmFsdWVzIG9mIHRoZSByZWdpc3RyeSBhcmUgYXMgc2hvd24gaW4gdGhlDQogICBm b2xsb3dpbmcgdGFibGU6DQoNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rDQog ICB8IFB1cnBvc2UgICAgICAgICAgfCBSZWZlcmVuY2UgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLSsNCiAgIHwgaWNvbiAgICAgICAgICAgICB8IFJGQyAzMjYxICB8DQogICB8 IGluZm8gICAgICAgICAgICAgfCBSRkMgMzI2MSAgfA0KICAgfCBjYXJkICAgICAgICAgICAgIHwg UkZDIDMyNjEgIHwNCiAgIHwgbGlzdC1tYW5hZ2VtZW50ICB8IFJGQyA1MzY3ICB8DQogICArLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKw0KDQoNCjMgIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgaW50cm9kdWNlIGFueSBzZWN1cml0eSBy aXNrcyB0byB0aGUgU0lQDQogICBwcm90b2NvbC4NCg0KDQoNCjUgIFJlZmVyZW5jZXMNCg0KNS4x ICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbS0VZV09SRFNdIEJyYWRuZXIsIFMuLCAiS2V5 IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJl bWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQogDQoNCg0KPEF1 dGhvcj4gICAgICAgICAgICAgICAgIEV4cGlyZXMgPEV4cGlyeSBEYXRlPiAgICAgICAgICAgICAg ICAgIFtQYWdlIDNdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgICAgICAgPERvY3VtZW50IFRp dGxlPiAgICAgICAgICAgICAgICA8SXNzdWUgRGF0ZT4NCg0KDQogICBbUkZDMTc3Nl0gIENyb2Nr ZXIsIFMuLCAiVGhlIEFkZHJlc3MgaXMgdGhlIE1lc3NhZ2UiLCBSRkMgMTc3NiwgQXByaWwNCiAg ICAgICAgICAgICAgMSAxOTk1Lg0KDQogICBbVFJVVEhTXSAgIENhbGxvbiwgUi4sICJUaGUgVHdl bHZlIE5ldHdvcmtpbmcgVHJ1dGhzIiwgUkZDIDE5MjUsDQogICAgICAgICAgICAgIEFwcmlsIDEg MTk5Ni4NCg0KDQo1LjIgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW0VWSUxCSVRdICBC ZWxsb3ZpbiwgUy4sICJUaGUgU2VjdXJpdHkgRmxhZyBpbiB0aGUgSVB2NCBIZWFkZXIiLA0KICAg ICAgICAgICAgICBSRkMgMzUxNCwgQXByaWwgMSAyMDAzLg0KDQogICBbUkZDNTUxM10gIEZhcnJl bCwgQS4sICJJQU5BIENvbnNpZGVyYXRpb25zIGZvciBUaHJlZSBMZXR0ZXINCiAgICAgICAgICAg ICAgQWNyb255bXMiLCBSRkMgNTUxMywgQXByaWwgMSAyMDA5Lg0KDQogICBbUkZDNTUxNF0gIFZ5 bmNrZSwgRS4sICJJUHY2IG92ZXIgU29jaWFsIE5ldHdvcmtzIiwgUkZDIDU1MTQsIEFwcmlsIDEN CiAgICAgICAgICAgICAgMjAwOS4NCg0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQoNCiAgIE5h bWUNCiAgIGFuZA0KICAgQWRkcmVzcw0KDQogICBFTWFpbDogbmFtZUBleGFtcGxlLmNvbQ0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCjxBdXRob3I+ICAgICAg ICAgICAgICAgICBFeHBpcmVzIDxFeHBpcnkgRGF0ZT4gICAgICAgICAgICAgICAgICBbUGFnZSA0 XQ0K --_002_C563F76EA324474CA3722A35154AFDB3139DF35AAZUS1EXMB01glob_-- From pkyzivat@alum.mit.edu Mon Mar 4 13:26:43 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182F621F8706 for ; Mon, 4 Mar 2013 13:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 jZc1pr63s7br for ; Mon, 4 Mar 2013 13:26:42 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id D53E221F8702 for ; Mon, 4 Mar 2013 13:26:41 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta08.westchester.pa.mail.comcast.net with comcast id 7YLh1l0050vyq2s58ZShn2; Mon, 04 Mar 2013 21:26:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id 7ZSh1l0043ZTu2S3RZSh8q; Mon, 04 Mar 2013 21:26:41 +0000 Message-ID: <51351190.5040408@alum.mit.edu> Date: Tue, 05 Mar 2013 05:26:40 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362432401; bh=V+c6SmdZKxHDLcLPjb7OyLVXFxTQWE3lr5VdN+0i1yg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s2qKwscC88tpfKbFRsFsBkbCvr3woXQGcXtkUYAsXlmo7jpp/FlnvgqAiDj9DkaKa sI+KyhwzPo0bNJzymMncU1c11UKyfUdY1Y77qZ6vp9jg8mTDuk3L/3adF7z28ySKqm SV2STZHGP4e3VmubZT7eWkE407mOYuFKUnFwrKBKGNcXT1tvobOXaQsiBg0+/5zqbx hes7q52bgPhoo4E0ylNRzZ6ntUfHPTA7csLVRGPyiDKSAhQ0ZtwXz+csmp+sJCP3Yu +zH9Qjh2KcmNjz7ttMeYV8Gwm10nqOY+HWNqxbQ/ZrpRYr4PCULdxkGR9LgFHeAUns ivWw24Fuah1hw== Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 21:26:43 -0000 On 3/5/13 3:25 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Peter, > > Today, there is no registry for the "purpose" values in the Call-Info header. > Mary and I have an open issue around this in the following draft, as we would like to register a "ccmp" value. > https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-indication/?include_text=1 Recently sipcore seems to have gotten into the business of establishing missing registries for 3261. We can certainly do another one. Thanks, Paul > Please, keep us posted on your discussion with IANA on this. > > Regards, > Rifaat > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Peter Saint-Andre >> Sent: Monday, March 04, 2013 2:04 PM >> To: Olle E. Johansson >> Cc: Cullen Jennings (fluffy); dispatch@ietf.org; Emil Ivov >> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 3/4/13 1:51 AM, Olle E. Johansson wrote: >>> >>> 3 mar 2013 kl. 14:12 skrev "Cullen Jennings (fluffy)" >>> : >>> >>>> >>>> If you don't want to do the vcard but just want the xmpp address >>>> directly, I'd probably suggest something like >>>> >>>> Call-Info: ;purpose=impp >>>> >>>> To just indicate that the URL provided the IM and Presence >>>> service for that user >>>> >>>> RFC 3261 section 20.9 says that the IANA section of 3261 will >>>> define how to add a new purpose but as far as I can tell it does >>>> not. However, the IANA SIP registry for the URI purpose at >>>> >>>> http://www.iana.org/assignments/sip-parameters/sip- >> parameters.xml#sip-parameters-13 >>>> >>>> >>>> >> is just spec required so I think think you might be able to trivial add >> a "impp" purpose. >>> Shouldn't the purposes in RFC 3261 be added to that registry too? >> >> Hej Olle, >> >> Yeah, I went searching for those in the registry yesterday and >> couldn't find them. It sounds like someone needs to register them. >> >> RFC 3261 says: >> >> The Call-Info header field provides additional information about the >> caller or callee, depending on whether it is found in a request or >> response. The purpose of the URI is described by the "purpose" >> parameter. The "icon" parameter designates an image suitable as an >> iconic representation of the caller or callee. The "info" parameter >> describes the caller or callee in general, for example, through a >> web >> page. The "card" parameter provides a business card, for example, >> in >> vCard [36] or LDIF [37] formats. Additional tokens can be >> registered >> using IANA and the procedures in Section 27. >> >> Actually, I think "icon", "info", and "card" are values of the >> "purpose" parameter, not parameters in themselves, right? >> >> I find the Header Field Parameters and Parameter Values registry a bit >> confusing: >> >> https://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip- >> parameters-12 >> >> Some of those header fields have predefined values. It's not clear to >> me if those values need to be registered. Section 20.9 of RFC 3261 >> says they do, but Section 27 doesn't say how. (When oh when is someone >> going to work on 3261bis? ;-) >> >> Olle/Emil, how about you and I take this up with IANA folks during >> their office hours in Orlando? >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJRNPAPAAoJEOoGpJErxa2pgvwP/jnZrFSx3H82349715qd6jN2 >> /rWF+VLF73tEBHX/ssBaBr4Kwu/RJ+oYK6+jNYbpiq9cmUEsSLjOJOY0frygUHej >> rE/uV5CtXwkn453yWX2ocEUHXI5bnrgENXxqPy2YITXETogf+Ybbs00IrvneMzdL >> FVnxYXFYVWKmKIPbgrGxVD4xDH030yQyxzewUDm6TrF/R3LoSlwULYxle4jfgyYm >> 3bVh64DBsQto39MvtY32abHP1WF1Iav76o7GT0aBb3A09Xv+NkmyRk3EpSbUpj0K >> 0zksaLV3bXivBKKjjC3tV9QiDPCD5bYfqQh5UyiJ+PVYOxGFOt191AfH+8oqyowV >> cpMXDWPeewRoUaskuTyXsPgL5TiCoeBzOgDF+SnLHk5Uq78tjyrH5YJOHD2Zd1AS >> LKn0Xqnb2yZdeFqCEoBAZfAo5W64dj5FF+03+98NxJ4IKFHBob6x/NpeSc3EAvit >> iJxzki6l+MpdK2yd6SbvaMPf2UlqOXBpPuDmxM1SlmgJbWFV3BpvoOjGGHGQcz+v >> 3W13GAv4HXp3LtpgCduAUtBmDsMxydPwy+Zsm2bhkr0XChK9VX2HqbktaU2qOHU5 >> QOLqLh5RWFcdK4WVkEtqoNvwHVFq53zC25Ujnq/niBUBm7lvHpuO0E029Gu0AtMY >> WnUZHMGNtbAV+KlfHip2 >> =7auh >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 stpeter@stpeter.im Mon Mar 4 13:29:32 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AD921F8C8D for ; Mon, 4 Mar 2013 13:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 RgmjABdxpULX for ; Mon, 4 Mar 2013 13:29:31 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3B85721F8C05 for ; Mon, 4 Mar 2013 13:29:31 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 469AA4004E; Mon, 4 Mar 2013 14:37:38 -0700 (MST) Message-ID: <51351234.50104@stpeter.im> Date: Mon, 04 Mar 2013 14:29:24 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51350201.6090507@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Cullen Jennings \(fluffy\)" , Emil Ivov , "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 21:29:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/4/13 2:08 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Peter, > > Take a look at the attached document and let me know if that is > good enough as a starting point. Looks good, thanks! Per Paul's note, you probably want to chat with the sipcore chairs about it. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNRI0AAoJEOoGpJErxa2pmssQAIpL3fJ7xq9Ag++p/0+Vz2uu Z4PUuTecUi9ibWiibft6ZT8eu6357ggqReK0cbQhyay8BtAqocwSEZanpaux+idB WEaKKCvEbxB9v3zqJtaYytiCtL+cpHaBbg9ZoDyj75L2g6K3Q79rP/Mdhu14yw9z srqhQTgexF4gDwB9J7qdgmk9pCTAHNxWwE2uFhkUTk4fXlF1C5jD3kXeeSEW6nTg Y0QVE7f4qrCEUaqseU4dqMw6vwoNHDvZ0svcDgTg3tUEnepv0bZt8ziR6Efomz5z zt3vsTQTiqvx9UvtKdz1lbVtYwhYYmaGE3q1Rl2KNYpUOXmV/0YGCi/5ttTFcaxb derpd/ddeMJHYCV1+VK6RE3mJvSyjTfzZIbXKAYv3i07uQPmuONY4JXlIoYH4jU3 CXuenZDpNCUJqphiFYqOghOARPHPQ8J6S8xcK9xjYYh6boU12bKg1l/NcD7FeWPe 0di9hpFA8Q2lk/4dbEvbKcM5/jYY+jJc/Xhc4QHo6t2/sp265373hgN/USOFjhAm Prf28VbgBODBj8HPNBrl4leuEtRCQh63q4UZoPTG05SVBODolHBtVfLZ1MpIuz08 UeKr4mSXSllH0fnpYJ2llR6fRYa6McmgeUFgV4mJVU1s7UbBt56Mt7d7Vxl9sVTi dIOH7K6Z7eyw/HM5Gpx4 =55PN -----END PGP SIGNATURE----- From rifatyu@avaya.com Mon Mar 4 13:51:18 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1D021F8C54 for ; Mon, 4 Mar 2013 13:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 6JTVVfXBecuF for ; Mon, 4 Mar 2013 13:51:17 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id E05B821F83E1 for ; Mon, 4 Mar 2013 13:51:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALh+MVGHCzI1/2dsb2JhbAA7CQ6CWL9egQAWc4IfAQEBAQMBAQEPKDQXBAIBCA0BAwQBAQEKFAkHJwsUCQgCBAESCAEZh3EBC6QcnEONU4EZJhIGgllhA5xcilKCST+CJw X-IronPort-AV: E=Sophos;i="4.84,766,1355115600"; d="scan'208";a="260630" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Mar 2013 16:51:16 -0500 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Mar 2013 16:49:54 -0500 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.02.0328.009; Mon, 4 Mar 2013 16:51:15 -0500 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity Thread-Index: AQHOGQr9SIPFU2v3v02dtExy7g61EJiV51LAgAB4VAD//7HV4A== Date: Mon, 4 Mar 2013 21:51:15 +0000 Message-ID: References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51351190.5040408@alum.mit.edu> In-Reply-To: <51351190.5040408@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 21:51:18 -0000 Ok. I will clean up the draft and submit it to the SIPCORE when the submiss= ion tool reopens next week. Regards, Rifaat > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Monday, March 04, 2013 4:27 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] URI schemes in P-Asserted-Identity >=20 > On 3/5/13 3:25 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Peter, > > > > Today, there is no registry for the "purpose" values in the Call-Info > header. > > Mary and I have an open issue around this in the following draft, as > we would like to register a "ccmp" value. > > https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp- > indication/?include_text=3D1 >=20 > Recently sipcore seems to have gotten into the business of establishing > missing registries for 3261. We can certainly do another one. >=20 > Thanks, > Paul >=20 > > Please, keep us posted on your discussion with IANA on this. > > > > Regards, > > Rifaat > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > >> Behalf Of Peter Saint-Andre > >> Sent: Monday, March 04, 2013 2:04 PM > >> To: Olle E. Johansson > >> Cc: Cullen Jennings (fluffy); dispatch@ietf.org; Emil Ivov > >> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 3/4/13 1:51 AM, Olle E. Johansson wrote: > >>> > >>> 3 mar 2013 kl. 14:12 skrev "Cullen Jennings (fluffy)" > >>> : > >>> > >>>> > >>>> If you don't want to do the vcard but just want the xmpp address > >>>> directly, I'd probably suggest something like > >>>> > >>>> Call-Info: ;purpose=3Dimpp > >>>> > >>>> To just indicate that the URL provided the IM and Presence > >>>> service for that user > >>>> > >>>> RFC 3261 section 20.9 says that the IANA section of 3261 will > >>>> define how to add a new purpose but as far as I can tell it does > >>>> not. However, the IANA SIP registry for the URI purpose at > >>>> > >>>> http://www.iana.org/assignments/sip-parameters/sip- > >> parameters.xml#sip-parameters-13 > >>>> > >>>> > >>>> > >> is just spec required so I think think you might be able to trivial > add > >> a "impp" purpose. > >>> Shouldn't the purposes in RFC 3261 be added to that registry too? > >> > >> Hej Olle, > >> > >> Yeah, I went searching for those in the registry yesterday and > >> couldn't find them. It sounds like someone needs to register them. > >> > >> RFC 3261 says: > >> > >> The Call-Info header field provides additional information about > the > >> caller or callee, depending on whether it is found in a request > or > >> response. The purpose of the URI is described by the "purpose" > >> parameter. The "icon" parameter designates an image suitable as > an > >> iconic representation of the caller or callee. The "info" > parameter > >> describes the caller or callee in general, for example, through > a > >> web > >> page. The "card" parameter provides a business card, for > example, > >> in > >> vCard [36] or LDIF [37] formats. Additional tokens can be > >> registered > >> using IANA and the procedures in Section 27. > >> > >> Actually, I think "icon", "info", and "card" are values of the > >> "purpose" parameter, not parameters in themselves, right? > >> > >> I find the Header Field Parameters and Parameter Values registry a > bit > >> confusing: > >> > >> https://www.iana.org/assignments/sip-parameters/sip- > parameters.xml#sip- > >> parameters-12 > >> > >> Some of those header fields have predefined values. It's not clear > to > >> me if those values need to be registered. Section 20.9 of RFC 3261 > >> says they do, but Section 27 doesn't say how. (When oh when is > someone > >> going to work on 3261bis? ;-) > >> > >> Olle/Emil, how about you and I take this up with IANA folks during > >> their office hours in Orlando? > >> > >> Peter > >> > >> - -- > >> Peter Saint-Andre > >> https://stpeter.im/ > >> > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >> > >> iQIcBAEBAgAGBQJRNPAPAAoJEOoGpJErxa2pgvwP/jnZrFSx3H82349715qd6jN2 > >> /rWF+VLF73tEBHX/ssBaBr4Kwu/RJ+oYK6+jNYbpiq9cmUEsSLjOJOY0frygUHej > >> rE/uV5CtXwkn453yWX2ocEUHXI5bnrgENXxqPy2YITXETogf+Ybbs00IrvneMzdL > >> FVnxYXFYVWKmKIPbgrGxVD4xDH030yQyxzewUDm6TrF/R3LoSlwULYxle4jfgyYm > >> 3bVh64DBsQto39MvtY32abHP1WF1Iav76o7GT0aBb3A09Xv+NkmyRk3EpSbUpj0K > >> 0zksaLV3bXivBKKjjC3tV9QiDPCD5bYfqQh5UyiJ+PVYOxGFOt191AfH+8oqyowV > >> cpMXDWPeewRoUaskuTyXsPgL5TiCoeBzOgDF+SnLHk5Uq78tjyrH5YJOHD2Zd1AS > >> LKn0Xqnb2yZdeFqCEoBAZfAo5W64dj5FF+03+98NxJ4IKFHBob6x/NpeSc3EAvit > >> iJxzki6l+MpdK2yd6SbvaMPf2UlqOXBpPuDmxM1SlmgJbWFV3BpvoOjGGHGQcz+v > >> 3W13GAv4HXp3LtpgCduAUtBmDsMxydPwy+Zsm2bhkr0XChK9VX2HqbktaU2qOHU5 > >> QOLqLh5RWFcdK4WVkEtqoNvwHVFq53zC25Ujnq/niBUBm7lvHpuO0E029Gu0AtMY > >> WnUZHMGNtbAV+KlfHip2 > >> =3D7auh > >> -----END PGP SIGNATURE----- > >> _______________________________________________ > >> 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 > > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From ibc@aliax.net Tue Mar 5 03:56:46 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066AC21F8717 for ; Tue, 5 Mar 2013 03:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 S273EylSeXkP for ; Tue, 5 Mar 2013 03:56:45 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 604FC21F8700 for ; Tue, 5 Mar 2013 03:56:45 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so1111213qca.17 for ; Tue, 05 Mar 2013 03:56:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=PVgoitG6sKI4ZbZJwd5q58+Q3Trj/IGS7PSsPWDWbv4=; b=aa0OuafXNM+KfPVVX1Frm1LaIBPDKtAdEeIeyiXHesPhCcGS+r9mDKlC6oDf2FQzqu ps66HJ5HeXtXVhc1IxD8KyumcOiVg6YKjfgRQWLuf0Q7ATqrdi12YR5Sj5keO98PaMbG nr4NdPAP7MZxqDags4onkeoJRWMi571DAoDzycbTr5TTEosr0g6+4TVMfUzd3MUONtWc o3lgyvA+DbKe0GkZPW/L7S/Lq1jiQHWFIgP8HljPV8res8hjKNfBS9UArHx0mnRQS0Wk BDuugqshR2CeoVI9/43dZa1m43y696ZFwUaZ1z9PcRtSlfSVKGVYalzpSm8ylMUBpOnP FjFg== X-Received: by 10.49.12.194 with SMTP id a2mr41231374qec.11.1362484604838; Tue, 05 Mar 2013 03:56:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.12.233 with HTTP; Tue, 5 Mar 2013 03:56:24 -0800 (PST) In-Reply-To: <512A8982.3080809@alum.mit.edu> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 5 Mar 2013 12:56:24 +0100 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQknUjytJ2v5ls9/hFin6Bt3YS5HQtA8fG8rUHBYSmHW14eGQZ43hbu+4DS5OCocZI0x4Eoj Cc: dispatch@ietf.org, stephane.cazeaux@orange.com Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 11:56:46 -0000 2013/2/24 Paul Kyzivat : > First, AFAIK there are currently no plans to put bfcp over a data channel= , > but I think there should be. > > My reason is because that is a mechanism that could be supported by a an > RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint ma= y > still need to support bfcp over tcp or udp for legacy interworking. > > It would also be possible for an RTCWEB clue client to use bfcp over a > websocket. > > The question is: how many of these alternatives do we want to define and > then ask people to support in their products. The more alternatives we ha= ve > the less likely we are to get interoperability. Hi, WebSocket is an already existing protocol implemented in both clients (mostly web browsers) and servers (there are tons of WebSocket server implementations). In the other side WebRTC Data Channel will be first implemented as a direct communication mechanism between browsers and, maybe in a future, there will appear *complex* server side implementations (which all the SCTP-over-DTLS-over-UDP that Data Channel requires). I don't know BFCP protocol but it seems to be a protocol to "manage a conference server", am I right? If so, WebSocket protocol already provides the pieces for carrying BFCP messages from WebSocket capable clients to a WebSocket server. Doing the same with Data Channel will require much more work. --=20 I=C3=B1aki Baz Castillo From keith.drage@alcatel-lucent.com Tue Mar 5 04:11:18 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B5021F890D for ; Tue, 5 Mar 2013 04:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 uaQjZwISNec1 for ; Tue, 5 Mar 2013 04:11:17 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7007721F8915 for ; Tue, 5 Mar 2013 04:11:15 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r25C9roq001425 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Mar 2013 13:10:48 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 5 Mar 2013 13:10:40 +0100 From: "DRAGE, Keith (Keith)" To: "Shekh-Yusef, Rifaat (Rifaat)" , Paul Kyzivat , "dispatch@ietf.org" Date: Tue, 5 Mar 2013 13:10:39 +0100 Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity Thread-Index: AQHOGQr9SIPFU2v3v02dtExy7g61EJiV51LAgAB4VAD//7HV4IAA6MyQ Message-ID: References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51351190.5040408@alum.mit.edu> 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-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 12:11:19 -0000 Remember that the IANA considerations needs to deal with all existing usage= s and that now includes bliss-call-completions. If you create a new registry, you need to define the policy for adding to t= hat registry. This is the "purpose" header field parameter, rather than just "purpose" pa= rameter. Amend throughout. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Shekh-Yusef, Rifaat (Rifaat) > Sent: 04 March 2013 21:51 > To: Paul Kyzivat; dispatch@ietf.org > Subject: Re: [dispatch] URI schemes in P-Asserted-Identity >=20 > Ok. I will clean up the draft and submit it to the SIPCORE when the > submission tool reopens next week. >=20 > Regards, > Rifaat >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Monday, March 04, 2013 4:27 PM > > To: dispatch@ietf.org > > Subject: Re: [dispatch] URI schemes in P-Asserted-Identity > > > > On 3/5/13 3:25 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > > Peter, > > > > > > Today, there is no registry for the "purpose" values in the Call-Info > > header. > > > Mary and I have an open issue around this in the following draft, as > > we would like to register a "ccmp" value. > > > https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp- > > indication/?include_text=3D1 > > > > Recently sipcore seems to have gotten into the business of establishing > > missing registries for 3261. We can certainly do another one. > > > > Thanks, > > Paul > > > > > Please, keep us posted on your discussion with IANA on this. > > > > > > Regards, > > > Rifaat > > > > > > > > >> -----Original Message----- > > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > > On > > >> Behalf Of Peter Saint-Andre > > >> Sent: Monday, March 04, 2013 2:04 PM > > >> To: Olle E. Johansson > > >> Cc: Cullen Jennings (fluffy); dispatch@ietf.org; Emil Ivov > > >> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity > > >> > > >> -----BEGIN PGP SIGNED MESSAGE----- > > >> Hash: SHA1 > > >> > > >> On 3/4/13 1:51 AM, Olle E. Johansson wrote: > > >>> > > >>> 3 mar 2013 kl. 14:12 skrev "Cullen Jennings (fluffy)" > > >>> : > > >>> > > >>>> > > >>>> If you don't want to do the vcard but just want the xmpp address > > >>>> directly, I'd probably suggest something like > > >>>> > > >>>> Call-Info: ;purpose=3Dimpp > > >>>> > > >>>> To just indicate that the URL provided the IM and Presence > > >>>> service for that user > > >>>> > > >>>> RFC 3261 section 20.9 says that the IANA section of 3261 will > > >>>> define how to add a new purpose but as far as I can tell it does > > >>>> not. However, the IANA SIP registry for the URI purpose at > > >>>> > > >>>> http://www.iana.org/assignments/sip-parameters/sip- > > >> parameters.xml#sip-parameters-13 > > >>>> > > >>>> > > >>>> > > >> is just spec required so I think think you might be able to trivial > > add > > >> a "impp" purpose. > > >>> Shouldn't the purposes in RFC 3261 be added to that registry too? > > >> > > >> Hej Olle, > > >> > > >> Yeah, I went searching for those in the registry yesterday and > > >> couldn't find them. It sounds like someone needs to register them. > > >> > > >> RFC 3261 says: > > >> > > >> The Call-Info header field provides additional information about > > the > > >> caller or callee, depending on whether it is found in a request > > or > > >> response. The purpose of the URI is described by the "purpose" > > >> parameter. The "icon" parameter designates an image suitable as > > an > > >> iconic representation of the caller or callee. The "info" > > parameter > > >> describes the caller or callee in general, for example, through > > a > > >> web > > >> page. The "card" parameter provides a business card, for > > example, > > >> in > > >> vCard [36] or LDIF [37] formats. Additional tokens can be > > >> registered > > >> using IANA and the procedures in Section 27. > > >> > > >> Actually, I think "icon", "info", and "card" are values of the > > >> "purpose" parameter, not parameters in themselves, right? > > >> > > >> I find the Header Field Parameters and Parameter Values registry a > > bit > > >> confusing: > > >> > > >> https://www.iana.org/assignments/sip-parameters/sip- > > parameters.xml#sip- > > >> parameters-12 > > >> > > >> Some of those header fields have predefined values. It's not clear > > to > > >> me if those values need to be registered. Section 20.9 of RFC 3261 > > >> says they do, but Section 27 doesn't say how. (When oh when is > > someone > > >> going to work on 3261bis? ;-) > > >> > > >> Olle/Emil, how about you and I take this up with IANA folks during > > >> their office hours in Orlando? > > >> > > >> Peter > > >> > > >> - -- > > >> Peter Saint-Andre > > >> https://stpeter.im/ > > >> > > >> > > >> -----BEGIN PGP SIGNATURE----- > > >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > > >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > >> > > >> iQIcBAEBAgAGBQJRNPAPAAoJEOoGpJErxa2pgvwP/jnZrFSx3H82349715qd6jN2 > > >> /rWF+VLF73tEBHX/ssBaBr4Kwu/RJ+oYK6+jNYbpiq9cmUEsSLjOJOY0frygUHej > > >> rE/uV5CtXwkn453yWX2ocEUHXI5bnrgENXxqPy2YITXETogf+Ybbs00IrvneMzdL > > >> FVnxYXFYVWKmKIPbgrGxVD4xDH030yQyxzewUDm6TrF/R3LoSlwULYxle4jfgyYm > > >> 3bVh64DBsQto39MvtY32abHP1WF1Iav76o7GT0aBb3A09Xv+NkmyRk3EpSbUpj0K > > >> 0zksaLV3bXivBKKjjC3tV9QiDPCD5bYfqQh5UyiJ+PVYOxGFOt191AfH+8oqyowV > > >> cpMXDWPeewRoUaskuTyXsPgL5TiCoeBzOgDF+SnLHk5Uq78tjyrH5YJOHD2Zd1AS > > >> LKn0Xqnb2yZdeFqCEoBAZfAo5W64dj5FF+03+98NxJ4IKFHBob6x/NpeSc3EAvit > > >> iJxzki6l+MpdK2yd6SbvaMPf2UlqOXBpPuDmxM1SlmgJbWFV3BpvoOjGGHGQcz+v > > >> 3W13GAv4HXp3LtpgCduAUtBmDsMxydPwy+Zsm2bhkr0XChK9VX2HqbktaU2qOHU5 > > >> QOLqLh5RWFcdK4WVkEtqoNvwHVFq53zC25Ujnq/niBUBm7lvHpuO0E029Gu0AtMY > > >> WnUZHMGNtbAV+KlfHip2 > > >> =3D7auh > > >> -----END PGP SIGNATURE----- > > >> _______________________________________________ > > >> 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From rifatyu@avaya.com Tue Mar 5 04:37:48 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E5521F8739 for ; Tue, 5 Mar 2013 04:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 0fE5Eqkt8vqi for ; Tue, 5 Mar 2013 04:37:47 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id ED03721F87F3 for ; Tue, 5 Mar 2013 04:37:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALh+MVHGmAcF/2dsb2JhbAA7CYJmv16BABZzgh8BAQEBAgEBAQEPKDQLBQcEAgEIDQQEAQEBHgkHJwsUCQgCBA4FCRmHawYBC6QcjGuPWI1TgRcoCwcGgllhA5ZDhhmKUoMI X-IronPort-AV: E=Sophos;i="4.84,766,1355115600"; d="scan'208";a="367425" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 05 Mar 2013 07:37:45 -0500 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Mar 2013 07:37:01 -0500 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Tue, 5 Mar 2013 07:37:44 -0500 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "DRAGE, Keith (Keith)" Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity Thread-Index: AQHOGQr9SIPFU2v3v02dtExy7g61EJiV51LAgAB4VAD//7HV4IAA6MyQgAAQGgE= Date: Tue, 5 Mar 2013 12:37:44 +0000 Message-ID: References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51351190.5040408@alum.mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 12:37:48 -0000 Thanks Keith, I will address your comments in the sipcore -00 draft. Regards, Rifaat Sent from my iPhone On 2013-03-05, at 7:11 AM, "DRAGE, Keith (Keith)" wrote: > Remember that the IANA considerations needs to deal with all existing usa= ges and that now includes bliss-call-completions. >=20 > If you create a new registry, you need to define the policy for adding to= that registry. >=20 > This is the "purpose" header field parameter, rather than just "purpose" = parameter. Amend throughout. >=20 > Keith >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Shekh-Yusef, Rifaat (Rifaat) >> Sent: 04 March 2013 21:51 >> To: Paul Kyzivat; dispatch@ietf.org >> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity >>=20 >> Ok. I will clean up the draft and submit it to the SIPCORE when the >> submission tool reopens next week. >>=20 >> Regards, >> Rifaat >>=20 >>=20 >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Monday, March 04, 2013 4:27 PM >>> To: dispatch@ietf.org >>> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity >>>=20 >>> On 3/5/13 3:25 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >>>> Peter, >>>>=20 >>>> Today, there is no registry for the "purpose" values in the Call-Info >>> header. >>>> Mary and I have an open issue around this in the following draft, as >>> we would like to register a "ccmp" value. >>>> https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp- >>> indication/?include_text=3D1 >>>=20 >>> Recently sipcore seems to have gotten into the business of establishing >>> missing registries for 3261. We can certainly do another one. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Please, keep us posted on your discussion with IANA on this. >>>>=20 >>>> Regards, >>>> Rifaat >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>> On >>>>> Behalf Of Peter Saint-Andre >>>>> Sent: Monday, March 04, 2013 2:04 PM >>>>> To: Olle E. Johansson >>>>> Cc: Cullen Jennings (fluffy); dispatch@ietf.org; Emil Ivov >>>>> Subject: Re: [dispatch] URI schemes in P-Asserted-Identity >>>>>=20 >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>>=20 >>>>> On 3/4/13 1:51 AM, Olle E. Johansson wrote: >>>>>>=20 >>>>>> 3 mar 2013 kl. 14:12 skrev "Cullen Jennings (fluffy)" >>>>>> : >>>>>>=20 >>>>>>>=20 >>>>>>> If you don't want to do the vcard but just want the xmpp address >>>>>>> directly, I'd probably suggest something like >>>>>>>=20 >>>>>>> Call-Info: ;purpose=3Dimpp >>>>>>>=20 >>>>>>> To just indicate that the URL provided the IM and Presence >>>>>>> service for that user >>>>>>>=20 >>>>>>> RFC 3261 section 20.9 says that the IANA section of 3261 will >>>>>>> define how to add a new purpose but as far as I can tell it does >>>>>>> not. However, the IANA SIP registry for the URI purpose at >>>>>>>=20 >>>>>>> http://www.iana.org/assignments/sip-parameters/sip- >>>>> parameters.xml#sip-parameters-13 >>>>> is just spec required so I think think you might be able to trivial >>> add >>>>> a "impp" purpose. >>>>>> Shouldn't the purposes in RFC 3261 be added to that registry too? >>>>>=20 >>>>> Hej Olle, >>>>>=20 >>>>> Yeah, I went searching for those in the registry yesterday and >>>>> couldn't find them. It sounds like someone needs to register them. >>>>>=20 >>>>> RFC 3261 says: >>>>>=20 >>>>> The Call-Info header field provides additional information about >>> the >>>>> caller or callee, depending on whether it is found in a request >>> or >>>>> response. The purpose of the URI is described by the "purpose" >>>>> parameter. The "icon" parameter designates an image suitable as >>> an >>>>> iconic representation of the caller or callee. The "info" >>> parameter >>>>> describes the caller or callee in general, for example, through >>> a >>>>> web >>>>> page. The "card" parameter provides a business card, for >>> example, >>>>> in >>>>> vCard [36] or LDIF [37] formats. Additional tokens can be >>>>> registered >>>>> using IANA and the procedures in Section 27. >>>>>=20 >>>>> Actually, I think "icon", "info", and "card" are values of the >>>>> "purpose" parameter, not parameters in themselves, right? >>>>>=20 >>>>> I find the Header Field Parameters and Parameter Values registry a >>> bit >>>>> confusing: >>>>>=20 >>>>> https://www.iana.org/assignments/sip-parameters/sip- >>> parameters.xml#sip- >>>>> parameters-12 >>>>>=20 >>>>> Some of those header fields have predefined values. It's not clear >>> to >>>>> me if those values need to be registered. Section 20.9 of RFC 3261 >>>>> says they do, but Section 27 doesn't say how. (When oh when is >>> someone >>>>> going to work on 3261bis? ;-) >>>>>=20 >>>>> Olle/Emil, how about you and I take this up with IANA folks during >>>>> their office hours in Orlando? >>>>>=20 >>>>> Peter >>>>>=20 >>>>> - -- >>>>> Peter Saint-Andre >>>>> https://stpeter.im/ >>>>>=20 >>>>>=20 >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>>>=20 >>>>> iQIcBAEBAgAGBQJRNPAPAAoJEOoGpJErxa2pgvwP/jnZrFSx3H82349715qd6jN2 >>>>> /rWF+VLF73tEBHX/ssBaBr4Kwu/RJ+oYK6+jNYbpiq9cmUEsSLjOJOY0frygUHej >>>>> rE/uV5CtXwkn453yWX2ocEUHXI5bnrgENXxqPy2YITXETogf+Ybbs00IrvneMzdL >>>>> FVnxYXFYVWKmKIPbgrGxVD4xDH030yQyxzewUDm6TrF/R3LoSlwULYxle4jfgyYm >>>>> 3bVh64DBsQto39MvtY32abHP1WF1Iav76o7GT0aBb3A09Xv+NkmyRk3EpSbUpj0K >>>>> 0zksaLV3bXivBKKjjC3tV9QiDPCD5bYfqQh5UyiJ+PVYOxGFOt191AfH+8oqyowV >>>>> cpMXDWPeewRoUaskuTyXsPgL5TiCoeBzOgDF+SnLHk5Uq78tjyrH5YJOHD2Zd1AS >>>>> LKn0Xqnb2yZdeFqCEoBAZfAo5W64dj5FF+03+98NxJ4IKFHBob6x/NpeSc3EAvit >>>>> iJxzki6l+MpdK2yd6SbvaMPf2UlqOXBpPuDmxM1SlmgJbWFV3BpvoOjGGHGQcz+v >>>>> 3W13GAv4HXp3LtpgCduAUtBmDsMxydPwy+Zsm2bhkr0XChK9VX2HqbktaU2qOHU5 >>>>> QOLqLh5RWFcdK4WVkEtqoNvwHVFq53zC25Ujnq/niBUBm7lvHpuO0E029Gu0AtMY >>>>> WnUZHMGNtbAV+KlfHip2 >>>>> =3D7auh >>>>> -----END PGP SIGNATURE----- >>>>> _______________________________________________ >>>>> 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 >>>=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 stpeter@stpeter.im Tue Mar 5 08:59:48 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA9921F85D7 for ; Tue, 5 Mar 2013 08:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Y9yNoWZ6MbME for ; Tue, 5 Mar 2013 08:59:48 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4310D21F85D6 for ; Tue, 5 Mar 2013 08:59:48 -0800 (PST) Received: from [10.0.0.2] (unknown [24.9.182.250]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8E09F403CD; Tue, 5 Mar 2013 10:07:58 -0700 (MST) Message-ID: <51362484.4040003@stpeter.im> Date: Tue, 05 Mar 2013 09:59:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51351190.5040408@alum.mit.edu> , In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 16:59:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/5/13 5:37 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Thanks Keith, > > I will address your comments in the sipcore -00 draft. > > Regards, Rifaat > > Sent from my iPhone > > On 2013-03-05, at 7:11 AM, "DRAGE, Keith (Keith)" > wrote: > >> Remember that the IANA considerations needs to deal with all >> existing usages and that now includes bliss-call-completions. >> >> If you create a new registry, you need to define the policy for >> adding to that registry. Rifaat, see RFC 5226 for the policy definitions. In the Applications Area folks have been trying to make it easier for people to register things, but that might not be true in RAI. We can discuss on SIPCORE, I suppose. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNiSEAAoJEOoGpJErxa2pcoQP/0vr3WOsmqrySpUU1onpbbn1 WrFF2CUf6gDHGrS2c4gbuQL0+aj0b6v6PBJMeCKl6dEI5fcUD5pBmaaL/ZeJsc2w zQIdupghswJO/O3FJjws+ckPl7JUNR4pauxrk8C6YVXwUdYK9AyF8cqRfTntdSSK jJXu41r0VobLcmlYIeSmz3wMiQ5UmfIoLRwoIaVT75pZsEr0G85dWt+eTFdb7pYD raSW36dCkWtjb0bpA0qVD28YERTilLpztMc+2itu07URPzLGiJj4w15c7z6/Qjyr /0jncCESzj58kRQnfCAOXiQ8LRWypsLBr2TTIGb7qgCNQ8YR3qeUSPykQkZ5xRFK 7lBmMJ+WIxwsWKs/vkfvcoi+NFN6eANdIJPET6aRbuGhRpOpiuWVVF+NPltMWBKK lXZfMZ+ctLIkkM0kBEfm433JqnB165TPFQGRvfQNXNefSzHzdIK/QYFxwI8ZZMPD 6B9b3TkALoUxF/g7iCK8eLhcE9FNTm0xgmhyAzyD6aM/xT3ZawlUE1v79/OouImh dPIgUorR3x+Jscb6N2R4vk03T6kAy2X3VMwKOvvjBbNtOu/qp0rMbwo+8gqI6e8Y VHg9hCt9PVr3dHgLKdWeiXPlV6rEOSpIa6ER0gyK9n3cPM8V3oYB9Mz3cB0AogAu MzvmHcsQBHypy0cUEY/j =rV3E -----END PGP SIGNATURE----- From pkyzivat@alum.mit.edu Tue Mar 5 10:29:20 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C915F21F84CD for ; Tue, 5 Mar 2013 10:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 mf1RsnFkl7ln for ; Tue, 5 Mar 2013 10:29:20 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 337EE21F84CA for ; Tue, 5 Mar 2013 10:29:20 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta03.westchester.pa.mail.comcast.net with comcast id 7nUL1l00G0QuhwU53uVKy2; Tue, 05 Mar 2013 18:29:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id 7uVK1l00G3ZTu2S3NuVKVh; Tue, 05 Mar 2013 18:29:19 +0000 Message-ID: <5136397F.3000002@alum.mit.edu> Date: Wed, 06 Mar 2013 02:29:19 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362508159; bh=n8hsmDJLegFj05NIjcXYtfyFvxhFTFApu8ksTA3noFA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=q9qWZfvM30ox3Jk4OfftDeXm9I0N8iQjWPccqgam64sOEdHjXExtvIxDPqdO1DV1U GfT8DXq1MPo6i+dVyXiPqDq+CyzleAJ1BYbSn/RE9ns+zJ1Ai/ftnPgGj9eHjVaWaP aGMb9xB6Vp5CBMMdpXktWqqwALM8b0EV69VmIDSpaFFUOcuySTbnURftmAQ6Xa7ehC HWsQCmfskxwg3qVTh4sOO0hTDEk7+JQ17uoH5b2xnuASPXhdu+cAUyrdvBLEvTT5Ac BFnMAwMh2yeTmf6Kf1b62gxl4f/NFNicrJ8X3KTyHecnQY6Z54fDAsjSv+5RDx5qwz d7yggYokAvcVw== Cc: dispatch@ietf.org, stephane.cazeaux@orange.com Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 18:29:20 -0000 Iñaki, In the specific case of bfcp, it is likely that one end will always be on a server. (Its unlikely that one would want to use bfcp in a pt-pt call between two web clients.) So that makes websockets suitable, where it would be less so for something that might be used between two web clients. My point in bringing up the question is so that we consider the pros/cons in the context of the likely alternatives. Thanks, Paul On 3/5/13 7:56 PM, Iñaki Baz Castillo wrote: > 2013/2/24 Paul Kyzivat : >> First, AFAIK there are currently no plans to put bfcp over a data channel, >> but I think there should be. >> >> My reason is because that is a mechanism that could be supported by a an >> RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint may >> still need to support bfcp over tcp or udp for legacy interworking. >> >> It would also be possible for an RTCWEB clue client to use bfcp over a >> websocket. >> >> The question is: how many of these alternatives do we want to define and >> then ask people to support in their products. The more alternatives we have >> the less likely we are to get interoperability. > > > Hi, WebSocket is an already existing protocol implemented in both > clients (mostly web browsers) and servers (there are tons of WebSocket > server implementations). In the other side WebRTC Data Channel will be > first implemented as a direct communication mechanism between browsers > and, maybe in a future, there will appear *complex* server side > implementations (which all the SCTP-over-DTLS-over-UDP that Data > Channel requires). > > I don't know BFCP protocol but it seems to be a protocol to "manage a > conference server", am I right? If so, WebSocket protocol already > provides the pieces for carrying BFCP messages from WebSocket capable > clients to a WebSocket server. Doing the same with Data Channel will > require much more work. > From worley@shell01.TheWorld.com Tue Mar 5 10:32:04 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3796811E80B8 for ; Tue, 5 Mar 2013 10:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 lsYu33dNOlS0 for ; Tue, 5 Mar 2013 10:32:03 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09611E80A4 for ; Tue, 5 Mar 2013 10:32:02 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r25IViQD002262; Tue, 5 Mar 2013 13:31:47 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r25IVhmA3137689; Tue, 5 Mar 2013 13:31:43 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r25IVhGK3148124; Tue, 5 Mar 2013 13:31:43 -0500 (EST) Date: Tue, 5 Mar 2013 13:31:43 -0500 (EST) Message-Id: <201303051831.r25IVhGK3148124@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Shekh-Yusef, Rifaat (Rifaat)" In-reply-to: (rifatyu@avaya.com) References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51350201.6090507@stpeter.im> Cc: dispatch@ietf.org Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 18:32:04 -0000 > draft-yusef-dispatch-purpose-00.txt At the least, you need to include the value "call-completion", defined in draft-ietf-bliss-call-completion, which is now in the RFC Editor queue. But it's not clear to me that we need to go to this much effort, as there are currently only four documents that define values for this parameter, and their names fit into the space in http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-12 Dale From stpeter@stpeter.im Tue Mar 5 10:51:15 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A6211E8110 for ; Tue, 5 Mar 2013 10:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 LEItyWsSlcwU for ; Tue, 5 Mar 2013 10:51:14 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2BE11E80F5 for ; Tue, 5 Mar 2013 10:51:14 -0800 (PST) Received: from [10.0.0.2] (unknown [24.9.182.250]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 047A3403CD; Tue, 5 Mar 2013 11:59:24 -0700 (MST) Message-ID: <51363EA1.1090809@stpeter.im> Date: Tue, 05 Mar 2013 11:51:13 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Dale R. Worley" References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51350201.6090507@stpeter.im> <201303051831.r25IVhGK3148124@shell01.TheWorld.com> In-Reply-To: <201303051831.r25IVhGK3148124@shell01.TheWorld.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 18:51:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/5/13 11:31 AM, Dale R. Worley wrote: >> draft-yusef-dispatch-purpose-00.txt > > At the least, you need to include the value "call-completion", > defined in draft-ietf-bliss-call-completion, which is now in the > RFC Editor queue. > > But it's not clear to me that we need to go to this much effort, > as there are currently only four documents that define values for > this parameter, and their names fit into the space in > http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-12 Maybe > you're right. Section 20.9 of RFC 3261 states: The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. The existing registrations don't define a registry but instead ask that the relevant specification be added to the rightmost column. See for instance RFC 5367: ### 9.1. List-Management Purpose Parameter Value This document defines the 'list-management' value for the "purpose" parameter of the Call-Info header field. A reference to this RFC (in double brackets) has been added to the existing "purpose" Call-Info parameter entry in the SIP Parameters registry, which currently looks as follows: Predefined Header Field Parameter Name Values Reference ---------------------------- --------------- --------- --------- Call-Info purpose Yes [RFC3261] ### Similarly for draft-ietf-bliss-call-completion: ### 12.4. Call-Completion purpose parameter value This specification adds a new predefined value "call-completion" for the "purpose" header field parameter of the Call-Info header field. This modifies the registry header field parameters and parameter values by adding this RFC as a reference to the line for header field "Call-Info" and parameter name "purpose": Header Field: Call-Info Parameter Name: purpose Predefined Values: yes Reference: [RFC3261].[RFC5367][[RFC XXXX]] (Note for RFC Editor: Please fill in XXXX with the RFC number of this specification) ### While it would be nice if RFC 3261 defined the registration rules a bit more clearly, I suppose the current model is working fine and is used for a wide variety of header field parameters for SIP header field. If it's not broken, don't fix it. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNj6hAAoJEOoGpJErxa2pYacP/3Gsf5zn19Hs5r4+1POQISy0 K6ZtaQMz7gITcv+q2LWNhLP5KQDhG4OkAWrLoP6UarcggEfToOaD5pUPovXf3S0U kzNGZ3nFK4T2o3ave1omfJiCyoyuxVirHE2nOsVFmie1c92cRywzNO+d1lq7V7H1 UsDwpCigxsS3UcUFGgD+lv0uCIA8b2Dm2wCygZ5LTLbD9JJWsZinJ+GLRbMz0/ml GH45ydeS3oKqa6IPgDG8HggH9gjqNhdDYmNTrkcSb58rR6m8OOCka7EJpGbdRp2x XLb8uw24Eo0tKZ65SbCiTGKvlk0km0KheqAa0fo998+sNKCCbo/saz+HtBRSLOy0 y8W8UOPS4JXM13UAzY8yVoaqkzmOsRprnM6sQ3uhtZkFUCjlmAjBqkK74yo9YkRZ R5VuK5MhE9BD7AsDW+zRbOaxSAIy3/8gr/hzJHuUqXYpoLn1O6BtycxIoqyc4jj1 LyGEv/4LGw/Fz2th18k0+q+CTh/puN3IyAZLUDdo7l+ucl7BwHLV/FE03wlD9MvF V3TQuKFgjMZdP6KwcQgXsCiZvslAKfVYsn8kIMLP7pYj4xKSWoGXiN5AE5cz4xC/ CVhWxX0WpocGWO/WzXtvzC705l8TqF8E/ydAyl+A722tsLwuV/JLb818khDreYog pF7vQfhYDOxU3AjJ1Bvu =NwTt -----END PGP SIGNATURE----- From salvatore.loreto@ericsson.com Tue Mar 5 10:56:49 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBCE11E80E9 for ; Tue, 5 Mar 2013 10:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 2jsKV0iDj740 for ; Tue, 5 Mar 2013 10:56:48 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9C711E8108 for ; Tue, 5 Mar 2013 10:56:47 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-58-51363fe2ccb2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 13.BD.32353.2EF36315; Tue, 5 Mar 2013 19:56:35 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Tue, 5 Mar 2013 19:56:34 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 464CB2AC8 for ; Tue, 5 Mar 2013 20:56:34 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B87EB54649 for ; Tue, 5 Mar 2013 20:56:31 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4308553CE6 for ; Tue, 5 Mar 2013 20:56:31 +0200 (EET) Message-ID: <51363FE0.8040305@ericsson.com> Date: Tue, 5 Mar 2013 19:56:32 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <5136397F.3000002@alum.mit.edu> In-Reply-To: <5136397F.3000002@alum.mit.edu> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvje5je7NAg4PvuCyWTlrA6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGuzljAWHBCtOHeznbWBcbJgFyMnh4SAicSl+8/ZIGwxiQv3 1oPZQgInGSU2dbl0MXIB2esZJS6//sQKkbjEKHH8JzdE4iijxPKLH1ghnHOMEvsOTWQBqeIV 0JY4fXoVM4jNIqAiMefsQ0YQm03ATOL5wy1gcVGBZIl/j44wQtQLSpyc+QSsV0RAVGL+ikXs ILawQJLEi65uFogFzSwSk1tvMIEkOAV0JI7OWw12ErOAhcTiNwfZIWx5ieats5kh/lGTuHpu EzPE2VoSvWc7mSYwisxCsm8WkvZZSNoXMDKvYmTPTczMSS8338QIDOaDW34b7GDcdF/sEKM0 B4uSOG+464UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyR/z4XR6rL9dqUXD/Fs337Ljvu jCRhVW+/3WsdjmT9P2suFnnfKDnot7TWXqbPmdL/rTevLnkhVLozNo8940Gd4rMD23y7MjML vu6f/++LzZFrq/zNdha+WO+1ZuvribcZjkp7ru3epl2hb+xzpe/Nz54rXZkTHZapXLsy2V2/ RHTrxD9ecz8qsRRnJBpqMRcVJwIAZ/CluzQCAAA= Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 18:56:49 -0000 On 3/5/13 7:29 PM, Paul Kyzivat wrote: > Iñaki, > > In the specific case of bfcp, it is likely that one end will always be > on a server. (Its unlikely that one would want to use bfcp in a pt-pt > call between two web clients.) So that makes websockets suitable, > where it would be less so for something that might be used between two > web clients. > > My point in bringing up the question is so that we consider the > pros/cons in the context of the likely alternatives. from the JavaScript API prospective the standardization effort in W3C is to make the WebSocket and DataChannel API behavior as similar as possible, so that they can be interchangeable. I hope this aim will be met. It make sense, and actually it is required, standardize the protocol transported over WebSocket (i.e. the WebSocket subprotocols). While at moment there is not a need to do that for DataChannel. my 2 cents /Salvatore > Thanks, > Paul > > On 3/5/13 7:56 PM, Iñaki Baz Castillo wrote: >> 2013/2/24 Paul Kyzivat : >>> First, AFAIK there are currently no plans to put bfcp over a data >>> channel, >>> but I think there should be. >>> >>> My reason is because that is a mechanism that could be supported by >>> a an >>> RTCWEB client. And yes, it indeed may be the case that a CLUE >>> endpoint may >>> still need to support bfcp over tcp or udp for legacy interworking. >>> >>> It would also be possible for an RTCWEB clue client to use bfcp over a >>> websocket. >>> >>> The question is: how many of these alternatives do we want to define >>> and >>> then ask people to support in their products. The more alternatives >>> we have >>> the less likely we are to get interoperability. >> >> >> Hi, WebSocket is an already existing protocol implemented in both >> clients (mostly web browsers) and servers (there are tons of WebSocket >> server implementations). In the other side WebRTC Data Channel will be >> first implemented as a direct communication mechanism between browsers >> and, maybe in a future, there will appear *complex* server side >> implementations (which all the SCTP-over-DTLS-over-UDP that Data >> Channel requires). >> >> I don't know BFCP protocol but it seems to be a protocol to "manage a >> conference server", am I right? If so, WebSocket protocol already >> provides the pieces for carrying BFCP messages from WebSocket capable >> clients to a WebSocket server. Doing the same with Data Channel will >> require much more work. >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Salvatore Loreto, PhD www.sloreto.com From pkyzivat@alum.mit.edu Tue Mar 5 11:07:24 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D6D11E80E9 for ; Tue, 5 Mar 2013 11:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.076 X-Spam-Level: X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 dVe7z0eFOIiS for ; Tue, 5 Mar 2013 11:07:23 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBC711E80D3 for ; Tue, 5 Mar 2013 11:07:23 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta02.westchester.pa.mail.comcast.net with comcast id 7suP1l0021ap0As51v7NBr; Tue, 05 Mar 2013 19:07:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 7v7N1l00X3ZTu2S3iv7NFb; Tue, 05 Mar 2013 19:07:22 +0000 Message-ID: <5136426A.3000504@alum.mit.edu> Date: Wed, 06 Mar 2013 03:07:22 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51350201.6090507@stpeter.im> <201303051831.r25IVhGK3148124@shell01.TheWorld.com> <51363EA1.1090809@stpeter.im> In-Reply-To: <51363EA1.1090809@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362510442; bh=It+o72ob/ZVNlo8UuTFSQYeUzi1UV1rjRIX6fr+d7XI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s3DvbMrP2q4fz0SYB6z2k/xNJbQFLhrgdLayQ9qgHvLT+9WxzUOJpoFiWuRqahx5H cQwLd+DlsX2bRblMyieQDy5EgJRhOdAtH1tcT0/FaP/zcFGbXbjFzPxRUtN3k0stnC scZmuIGOor5EE+1c0r/JwA09I1px23I+swjJnw/k21zRF3kfeyOEZjG5UsQLq/miqp G3e1LxXEDYQ5CfdHXSRYbVNb6B1psbG30QM2e/+EWQeFeyi67fyKluavZB4gT7LF/q c9fBcxuro3WC6+yT+YRS9bb/2neW+5TVxUhVn29eRtIYovAlDt47e95czaXLr0eB+W bfufdufLLkkDQ== Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 19:07:24 -0000 Yeah, sorry. I wasn't thinking. This is covered by RFC3968. You just need an RFC with IANA considerations add the new entry to the existing table. It doesn't need to be done in sipcore. Feel free to do it in XMPP, or as AD-sponsored. Thanks, Paul On 3/6/13 2:51 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/5/13 11:31 AM, Dale R. Worley wrote: >>> draft-yusef-dispatch-purpose-00.txt >> >> At the least, you need to include the value "call-completion", >> defined in draft-ietf-bliss-call-completion, which is now in the >> RFC Editor queue. >> >> But it's not clear to me that we need to go to this much effort, >> as there are currently only four documents that define values for >> this parameter, and their names fit into the space in >> http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-12 > > Maybe >> > you're right. > > Section 20.9 of RFC 3261 states: > > The Call-Info header field provides additional information about the > caller or callee, depending on whether it is found in a request or > response. The purpose of the URI is described by the "purpose" > parameter. The "icon" parameter designates an image suitable as an > iconic representation of the caller or callee. The "info" parameter > describes the caller or callee in general, for example, through a web > page. The "card" parameter provides a business card, for example, in > vCard [36] or LDIF [37] formats. Additional tokens can be registered > using IANA and the procedures in Section 27. > > The existing registrations don't define a registry but instead ask > that the relevant specification be added to the rightmost column. > > See for instance RFC 5367: > > ### > > 9.1. List-Management Purpose Parameter Value > > This document defines the 'list-management' value for the "purpose" > parameter of the Call-Info header field. A reference to this RFC (in > double brackets) has been added to the existing "purpose" Call-Info > parameter entry in the SIP Parameters registry, which currently looks > as follows: > > Predefined > Header Field Parameter Name Values Reference > ---------------------------- --------------- --------- --------- > Call-Info purpose Yes [RFC3261] > > ### > > Similarly for draft-ietf-bliss-call-completion: > > ### > > 12.4. Call-Completion purpose parameter value > > This specification adds a new predefined value "call-completion" for > the "purpose" header field parameter of the Call-Info header field. > This modifies the registry header field parameters and parameter > values by adding this RFC as a reference to the line for header field > "Call-Info" and parameter name "purpose": > > Header Field: Call-Info > > Parameter Name: purpose > > Predefined Values: yes > > Reference: [RFC3261].[RFC5367][[RFC XXXX]] > > (Note for RFC Editor: Please fill in XXXX with the RFC number of this > specification) > > ### > > While it would be nice if RFC 3261 defined the registration rules a > bit more clearly, I suppose the current model is working fine and is > used for a wide variety of header field parameters for SIP header > field. If it's not broken, don't fix it. :-) > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRNj6hAAoJEOoGpJErxa2pYacP/3Gsf5zn19Hs5r4+1POQISy0 > K6ZtaQMz7gITcv+q2LWNhLP5KQDhG4OkAWrLoP6UarcggEfToOaD5pUPovXf3S0U > kzNGZ3nFK4T2o3ave1omfJiCyoyuxVirHE2nOsVFmie1c92cRywzNO+d1lq7V7H1 > UsDwpCigxsS3UcUFGgD+lv0uCIA8b2Dm2wCygZ5LTLbD9JJWsZinJ+GLRbMz0/ml > GH45ydeS3oKqa6IPgDG8HggH9gjqNhdDYmNTrkcSb58rR6m8OOCka7EJpGbdRp2x > XLb8uw24Eo0tKZ65SbCiTGKvlk0km0KheqAa0fo998+sNKCCbo/saz+HtBRSLOy0 > y8W8UOPS4JXM13UAzY8yVoaqkzmOsRprnM6sQ3uhtZkFUCjlmAjBqkK74yo9YkRZ > R5VuK5MhE9BD7AsDW+zRbOaxSAIy3/8gr/hzJHuUqXYpoLn1O6BtycxIoqyc4jj1 > LyGEv/4LGw/Fz2th18k0+q+CTh/puN3IyAZLUDdo7l+ucl7BwHLV/FE03wlD9MvF > V3TQuKFgjMZdP6KwcQgXsCiZvslAKfVYsn8kIMLP7pYj4xKSWoGXiN5AE5cz4xC/ > CVhWxX0WpocGWO/WzXtvzC705l8TqF8E/ydAyl+A722tsLwuV/JLb818khDreYog > pF7vQfhYDOxU3AjJ1Bvu > =NwTt > -----END PGP SIGNATURE----- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From stpeter@stpeter.im Tue Mar 5 11:44:14 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FA121F84E2 for ; Tue, 5 Mar 2013 11:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 4TLn4Lctjy1K for ; Tue, 5 Mar 2013 11:44:13 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFB321F84DF for ; Tue, 5 Mar 2013 11:44:13 -0800 (PST) Received: from [10.0.0.2] (unknown [24.9.182.250]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 14B95403CD; Tue, 5 Mar 2013 12:52:24 -0700 (MST) Message-ID: <51364B0B.3040704@stpeter.im> Date: Tue, 05 Mar 2013 12:44:11 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Paul Kyzivat References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51350201.6090507@stpeter.im> <201303051831.r25IVhGK3148124@shell01.TheWorld.com> <51363EA1.1090809@stpeter.im> <5136426A.3000504@alum.mit.edu> In-Reply-To: <5136426A.3000504@alum.mit.edu> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 19:44:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/5/13 12:07 PM, Paul Kyzivat wrote: > Yeah, sorry. I wasn't thinking. This is covered by RFC3968. You > just need an RFC with IANA considerations add the new entry to the > existing table. It doesn't need to be done in sipcore. Feel free to > do it in XMPP, or as AD-sponsored. Yep. I'll submit something when the window opens and we'll take it from there (AD-sponsored seems fine to me but we'll see what the ADs have to say). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRNksLAAoJEOoGpJErxa2pjS0P/15+5WcZXGYnesWyZqBeDoku Iw5JIW7oZksrqJYfqBkz16ImjAV4YpRU2Lhe+DJrhH0Ci4xZxd/StLLnwYQE7FNy YU2kYZrAI0XMww4zK4wDSj979p/tAJYsJkjMVHhwJsfKkH2R+G7aBxUlox0SqDJ3 3lR6cnBm3HidQlDGYBI32gwHNbCoLTL8MA4BGU0hvpJVa6d6ikEfrbJRFYIi0Hri eyIcH8aWvwLGcEM9To1E6BlhtaYMYQ4riAB/IjcdjJ9uD1QmCD8iDQY7MrYLRGpp LD3VpGRuAVP7mm4Yj3IaNK2GdrvKZIMgVAyc2LpGXx9d5JFtu+trw3+YYu4tznB0 FZBh5UbdPLq3CK3sYJJ7+q3soWkLHMylXik1BgEy5LTaOW6tWzDH5Gzp4Hxt53YD g88bBzSwQflftbFOHoCAAIiBacs9omyeil0hGafrPifPHd2mF4Ktb2O9FrykI8+2 eusho5xqMsrAU81YcpNemnAiHTeLPSc4t/V0i7dZGeewORtUc8FI5qb3Zt1wTjSk g4zUf4eySyAH4Sec0iP6o8SNm/neYeEtVl+oXHGcQa0OdnUXIRS5+cKZYbCgcV0E Gz5vSFDXZQGlImPjZn93LNdgjyceA/32x3ClSecmLGflXuQoDOztfzCVHpAj36Ez sNSQhYGxL6G2aeGrZuo2 =XeZm -----END PGP SIGNATURE----- From eckelcu@cisco.com Tue Mar 5 11:51:06 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088E021F862D for ; Tue, 5 Mar 2013 11:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 pFbvNeM7yDXb for ; Tue, 5 Mar 2013 11:51:05 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A4B3921F862A for ; Tue, 5 Mar 2013 11:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4086; q=dns/txt; s=iport; t=1362513064; x=1363722664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cMeOYvg1EDWaiIFQMbVgqeT2PFUuh703CxuYHcr1Idk=; b=JDtkfGQGQZ5BtGxCBPXuTb6X0yHnypPXSA4QzOAYIawZWKGhtzRkk7Z5 r74qd2U6pkLCKo1Jj17mSXtm+p4E8hd9wOzVHmKxzNMpRR8SM0GMQwT8S dpp3G7Z4HOZLgtzHDVcdNLtcMKOSCTRh8lCExyqiHiuldpmloIiw/HUNj k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAL9LNlGtJV2Y/2dsb2JhbABEDohVvAN0eRZzgisBAQEDAQEBASARNAYLDAQCAQgOAwQBAQECAgYdAwICAiULFAEICAIEAQ0FCIgFBQEMqXmCQJAYBIEjjTkWEAsHBoInMmEDpziBUnc/gic X-IronPort-AV: E=Sophos;i="4.84,790,1355097600"; d="scan'208";a="184074341" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 05 Mar 2013 19:51:04 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r25Jp4Nu016058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Mar 2013 19:51:04 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 13:51:03 -0600 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [dispatch] Remapping existing protocols for web usage: websockets or data channels? Thread-Index: AQHOGZiTUVT75MOAv0O7fk1y9LK61JiX0BaA//+w2gA= Date: Tue, 5 Mar 2013 19:51:03 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047C73EC@xmb-aln-x08.cisco.com> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <5136397F.3000002@alum.mit.edu> In-Reply-To: <5136397F.3000002@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.63] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dispatch@ietf.org" , "stephane.cazeaux@orange.com" Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 19:51:06 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkaXNwYXRjaC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9m IFBhdWwgS3l6aXZhdA0KPiBTZW50OiBUdWVzZGF5LCBNYXJjaCAwNSwgMjAxMyAxMDoyOSBBTQ0K PiBUbzogScOxYWtpIEJheiBDYXN0aWxsbw0KPiBDYzogZGlzcGF0Y2hAaWV0Zi5vcmc7IHN0ZXBo YW5lLmNhemVhdXhAb3JhbmdlLmNvbQ0KPiBTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBSZW1hcHBp bmcgZXhpc3RpbmcgcHJvdG9jb2xzIGZvciB3ZWIgdXNhZ2U6DQo+IHdlYnNvY2tldHMgb3IgZGF0 YSBjaGFubmVscz8NCj4gDQo+IEnDsWFraSwNCj4gDQo+IEluIHRoZSBzcGVjaWZpYyBjYXNlIG9m IGJmY3AsIGl0IGlzIGxpa2VseSB0aGF0IG9uZSBlbmQgd2lsbCBhbHdheXMgYmUNCj4gb24gYSBz ZXJ2ZXIuIChJdHMgdW5saWtlbHkgdGhhdCBvbmUgd291bGQgd2FudCB0byB1c2UgYmZjcCBpbiBh IHB0LXB0DQo+IGNhbGwgYmV0d2VlbiB0d28gd2ViIGNsaWVudHMuKSBTbyB0aGF0IG1ha2VzIHdl YnNvY2tldHMgc3VpdGFibGUsIHdoZXJlDQo+IGl0IHdvdWxkIGJlIGxlc3Mgc28gZm9yIHNvbWV0 aGluZyB0aGF0IG1pZ2h0IGJlIHVzZWQgYmV0d2VlbiB0d28gd2ViDQo+IGNsaWVudHMuDQoNCkkg ZGlzYWdyZWUsIGluIHRoYXQgZXZlbiBpbiBhIHB0IHRvIHB0IGNhbGwsIEJGQ1AgaXMgdXNlZCB0 byBuZWdvdGlhdGUgd2hpY2ggZW5kcG9pbnQgaXMgYWxsb3dlZCB0byB0cmFuc21pdCBjb250ZW50 LiBUaGUgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGlzIHVzZWQgdG8gZGV0ZXJtaW5lIHdoaWNoIGVu ZCBzaG91bGQgYmUgdGhlIEJGQ1Agc2VydmVyIGFuZCB3aGljaCBzaG91bGQgYmUgdGhlIEJGQ1Ag Y2xpZW50LiBJbiB0aGUgY2FzZSBvZiBhIGNvbmZlcmVuY2UsIHRoZSBjb25mZXJlbmNlIHNlcnZl ciB0eXBpY2FsbHkgdHJpZXMgdG8gYmUgdGhlIEJGQ1Agc2VydmVyIGFuZCB0aGUgY29uZmVyZW5j ZSBwYXJ0aWNpcGFudHMgaGFwcGlseSBsZXQgaXQuDQoNCkNoZWVycywNCkNoYXJsZXMNCg0KPiAN Cj4gTXkgcG9pbnQgaW4gYnJpbmdpbmcgdXAgdGhlIHF1ZXN0aW9uIGlzIHNvIHRoYXQgd2UgY29u c2lkZXIgdGhlDQo+IHByb3MvY29ucyBpbiB0aGUgY29udGV4dCBvZiB0aGUgbGlrZWx5IGFsdGVy bmF0aXZlcy4NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPiBPbiAzLzUvMTMgNzo1NiBQ TSwgScOxYWtpIEJheiBDYXN0aWxsbyB3cm90ZToNCj4gPiAyMDEzLzIvMjQgUGF1bCBLeXppdmF0 IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+Og0KPiA+PiBGaXJzdCwgQUZBSUsgdGhlcmUgYXJlIGN1 cnJlbnRseSBubyBwbGFucyB0byBwdXQgYmZjcCBvdmVyIGEgZGF0YSBjaGFubmVsLA0KPiA+PiBi dXQgSSB0aGluayB0aGVyZSBzaG91bGQgYmUuDQo+ID4+DQo+ID4+IE15IHJlYXNvbiBpcyBiZWNh dXNlIHRoYXQgaXMgYSBtZWNoYW5pc20gdGhhdCBjb3VsZCBiZSBzdXBwb3J0ZWQgYnkgYSBhbg0K PiA+PiBSVENXRUIgY2xpZW50LiBBbmQgeWVzLCBpdCBpbmRlZWQgbWF5IGJlIHRoZSBjYXNlIHRo YXQgYSBDTFVFIGVuZHBvaW50DQo+IG1heQ0KPiA+PiBzdGlsbCBuZWVkIHRvIHN1cHBvcnQgYmZj cCBvdmVyIHRjcCBvciB1ZHAgZm9yIGxlZ2FjeSBpbnRlcndvcmtpbmcuDQo+ID4+DQo+ID4+IEl0 IHdvdWxkIGFsc28gYmUgcG9zc2libGUgZm9yIGFuIFJUQ1dFQiBjbHVlIGNsaWVudCB0byB1c2Ug YmZjcCBvdmVyIGENCj4gPj4gd2Vic29ja2V0Lg0KPiA+Pg0KPiA+PiBUaGUgcXVlc3Rpb24gaXM6 IGhvdyBtYW55IG9mIHRoZXNlIGFsdGVybmF0aXZlcyBkbyB3ZSB3YW50IHRvIGRlZmluZQ0KPiBh bmQNCj4gPj4gdGhlbiBhc2sgcGVvcGxlIHRvIHN1cHBvcnQgaW4gdGhlaXIgcHJvZHVjdHMuIFRo ZSBtb3JlIGFsdGVybmF0aXZlcyB3ZQ0KPiBoYXZlDQo+ID4+IHRoZSBsZXNzIGxpa2VseSB3ZSBh cmUgdG8gZ2V0IGludGVyb3BlcmFiaWxpdHkuDQo+ID4NCj4gPg0KPiA+IEhpLCBXZWJTb2NrZXQg aXMgYW4gYWxyZWFkeSBleGlzdGluZyBwcm90b2NvbCBpbXBsZW1lbnRlZCBpbiBib3RoDQo+ID4g Y2xpZW50cyAobW9zdGx5IHdlYiBicm93c2VycykgYW5kIHNlcnZlcnMgKHRoZXJlIGFyZSB0b25z IG9mIFdlYlNvY2tldA0KPiA+IHNlcnZlciBpbXBsZW1lbnRhdGlvbnMpLiBJbiB0aGUgb3RoZXIg c2lkZSBXZWJSVEMgRGF0YSBDaGFubmVsIHdpbGwgYmUNCj4gPiBmaXJzdCBpbXBsZW1lbnRlZCBh cyBhIGRpcmVjdCBjb21tdW5pY2F0aW9uIG1lY2hhbmlzbSBiZXR3ZWVuDQo+IGJyb3dzZXJzDQo+ ID4gYW5kLCBtYXliZSBpbiBhIGZ1dHVyZSwgdGhlcmUgd2lsbCBhcHBlYXIgKmNvbXBsZXgqIHNl cnZlciBzaWRlDQo+ID4gaW1wbGVtZW50YXRpb25zICh3aGljaCBhbGwgdGhlIFNDVFAtb3Zlci1E VExTLW92ZXItVURQIHRoYXQgRGF0YQ0KPiA+IENoYW5uZWwgcmVxdWlyZXMpLg0KPiA+DQo+ID4g SSBkb24ndCBrbm93IEJGQ1AgcHJvdG9jb2wgYnV0IGl0IHNlZW1zIHRvIGJlIGEgcHJvdG9jb2wg dG8gIm1hbmFnZSBhDQo+ID4gY29uZmVyZW5jZSBzZXJ2ZXIiLCBhbSBJIHJpZ2h0PyBJZiBzbywg V2ViU29ja2V0IHByb3RvY29sIGFscmVhZHkNCj4gPiBwcm92aWRlcyB0aGUgcGllY2VzIGZvciBj YXJyeWluZyBCRkNQIG1lc3NhZ2VzIGZyb20gV2ViU29ja2V0IGNhcGFibGUNCj4gPiBjbGllbnRz IHRvIGEgV2ViU29ja2V0IHNlcnZlci4gRG9pbmcgdGhlIHNhbWUgd2l0aCBEYXRhIENoYW5uZWwg d2lsbA0KPiA+IHJlcXVpcmUgbXVjaCBtb3JlIHdvcmsuDQo+ID4NCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRpc3BhdGNoIG1haWxpbmcg bGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Rpc3BhdGNoDQo= From keith.drage@alcatel-lucent.com Tue Mar 5 12:43:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC5C21F8A00 for ; Tue, 5 Mar 2013 12:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 itx4akmUiKXy for ; Tue, 5 Mar 2013 12:43:26 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id D76D121F8A11 for ; Tue, 5 Mar 2013 12:43:24 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r25KgfEK032724 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Mar 2013 21:43:19 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 5 Mar 2013 21:42:58 +0100 From: "DRAGE, Keith (Keith)" To: Peter Saint-Andre , Paul Kyzivat Date: Tue, 5 Mar 2013 21:42:57 +0100 Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity Thread-Index: Ac4Z2dPpvmAgGfL+ToSk/Un3H5sWKgABeJaA Message-ID: References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51350201.6090507@stpeter.im> <201303051831.r25IVhGK3148124@shell01.TheWorld.com> <51363EA1.1090809@stpeter.im> <5136426A.3000504@alum.mit.edu> <51364B0B.3040704@stpeter.im> In-Reply-To: <51364B0B.3040704@stpeter.im> 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.69 on 155.132.188.80 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 20:43:27 -0000 This applies if you do not want to change the registration policy for indiv= idual values from RFC 3968. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Peter Saint-Andre > Sent: 05 March 2013 19:44 > To: Paul Kyzivat > Cc: dispatch@ietf.org > Subject: Re: [dispatch] URI schemes in P-Asserted-Identity >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 3/5/13 12:07 PM, Paul Kyzivat wrote: > > Yeah, sorry. I wasn't thinking. This is covered by RFC3968. You > > just need an RFC with IANA considerations add the new entry to the > > existing table. It doesn't need to be done in sipcore. Feel free to > > do it in XMPP, or as AD-sponsored. >=20 > Yep. I'll submit something when the window opens and we'll take it > from there (AD-sponsored seems fine to me but we'll see what the ADs > have to say). >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQIcBAEBAgAGBQJRNksLAAoJEOoGpJErxa2pjS0P/15+5WcZXGYnesWyZqBeDoku > Iw5JIW7oZksrqJYfqBkz16ImjAV4YpRU2Lhe+DJrhH0Ci4xZxd/StLLnwYQE7FNy > YU2kYZrAI0XMww4zK4wDSj979p/tAJYsJkjMVHhwJsfKkH2R+G7aBxUlox0SqDJ3 > 3lR6cnBm3HidQlDGYBI32gwHNbCoLTL8MA4BGU0hvpJVa6d6ikEfrbJRFYIi0Hri > eyIcH8aWvwLGcEM9To1E6BlhtaYMYQ4riAB/IjcdjJ9uD1QmCD8iDQY7MrYLRGpp > LD3VpGRuAVP7mm4Yj3IaNK2GdrvKZIMgVAyc2LpGXx9d5JFtu+trw3+YYu4tznB0 > FZBh5UbdPLq3CK3sYJJ7+q3soWkLHMylXik1BgEy5LTaOW6tWzDH5Gzp4Hxt53YD > g88bBzSwQflftbFOHoCAAIiBacs9omyeil0hGafrPifPHd2mF4Ktb2O9FrykI8+2 > eusho5xqMsrAU81YcpNemnAiHTeLPSc4t/V0i7dZGeewORtUc8FI5qb3Zt1wTjSk > g4zUf4eySyAH4Sec0iP6o8SNm/neYeEtVl+oXHGcQa0OdnUXIRS5+cKZYbCgcV0E > Gz5vSFDXZQGlImPjZn93LNdgjyceA/32x3ClSecmLGflXuQoDOztfzCVHpAj36Ez > sNSQhYGxL6G2aeGrZuo2 > =3DXeZm > -----END PGP SIGNATURE----- > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Tue Mar 5 12:56:12 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BB121F897A for ; Tue, 5 Mar 2013 12:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 5vCwyqBdO7Gj for ; Tue, 5 Mar 2013 12:56:11 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 6607721F8976 for ; Tue, 5 Mar 2013 12:56:10 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id 7nyh1l00A1wpRvQ55wwAYu; Tue, 05 Mar 2013 20:56:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 7ww91l0173ZTu2S3eww9cf; Tue, 05 Mar 2013 20:56:10 +0000 Message-ID: <51365BE9.8080908@alum.mit.edu> Date: Wed, 06 Mar 2013 04:56:09 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Peter Saint-Andre References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51350201.6090507@stpeter.im> <201303051831.r25IVhGK3148124@shell01.TheWorld.com> <51363EA1.1090809@stpeter.im> <5136426A.3000504@alum.mit.edu> <51364B0B.3040704@stpeter.im> In-Reply-To: <51364B0B.3040704@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362516970; bh=zXYtEtWsag/zj5sbI0CsYuUOTy3QyUM9O4K9BMyo5dE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Z229696cEacvmH+55Cc5LwvUxVBog0lXqZuazNf2iiAXom/3uQrMgJKMK2SEnxzMY l/6A27wat24gb6dJcjaVx3eHJlt+v5aI+NHrP9xkZkkRVSUaZxMQ34+pKQBcjBM9Dm KC5a3jMhaRr4dbcK3woqjTRGqRxgycq8xrJA0a1R2rK+ATVgo041B2jkOVtLdmH1kv qzd21mPVmSpITyUMPq0qgYLljq38mOA4yoOgrlhIl45RhYoaVWZjXYFBcocvvai7k9 wbLGKq75J1/EgacwUhXj9o8m7tfXxm7xOm4S6sz0ItXnoPEo4YLO2uxFSbezVtKXhp EMJ0VDtfGaJIw== Cc: dispatch@ietf.org Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 20:56:12 -0000 On 3/6/13 3:44 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/5/13 12:07 PM, Paul Kyzivat wrote: >> Yeah, sorry. I wasn't thinking. This is covered by RFC3968. You >> just need an RFC with IANA considerations add the new entry to the >> existing table. It doesn't need to be done in sipcore. Feel free to >> do it in XMPP, or as AD-sponsored. > > Yep. I'll submit something when the window opens and we'll take it > from there (AD-sponsored seems fine to me but we'll see what the ADs > have to say). I've seen mention of using this either to include an xmpp URI or an http reference to a vcard. Is the plan for on, the other, or both? Thanks, Paul From pkyzivat@alum.mit.edu Tue Mar 5 13:01:03 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F262021F85F3 for ; Tue, 5 Mar 2013 13:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.06 X-Spam-Level: X-Spam-Status: No, score=-0.06 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 vvfMsv2dHnd9 for ; Tue, 5 Mar 2013 13:01:02 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 48AB621F8589 for ; Tue, 5 Mar 2013 13:01:02 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta04.westchester.pa.mail.comcast.net with comcast id 7wHb1l0010ldTLk54x11XE; Tue, 05 Mar 2013 21:01:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id 7x111l00V3ZTu2S3Qx11P2; Tue, 05 Mar 2013 21:01:01 +0000 Message-ID: <51365D0D.80202@alum.mit.edu> Date: Wed, 06 Mar 2013 05:01:01 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <5136397F.3000002@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828047C73EC@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047C73EC@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362517261; bh=TFpNQRrGAfX07KTRKTyeTk9BQMawm0hlyzyWvlzGXsU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=W/bUKawAc0JdeHhPU5LJcDn0bznsUnZGdx3+zL9905GOPuVInMTY2FS2E38Geo7HW rxQv96DbleNwcK83fxrpYTACzgJZ5OdDbMiHt1dQnj63AGFj1NBhAknPgXDITSCLBC wcgewj5NfuNt3BFM/U3Uo0+ByfDpY6+ZOjj1jDeXaBLHVhAgdGQJf8r8MKF/eLWF5F jLBZ7PTX6XkL659otocytas0muPmQj6Vl2RsrZGtwI0shAQdMMVDtWeu5J5utqx7wN QRU1p9npFjMvKNeAjdi2YaZeCVjYfCZNB34eehcAGuaGXPhMGb3Q5hRKXDABlE9TaL VbVBfn0Wn2BCQ== Cc: "dispatch@ietf.org" , "stephane.cazeaux@orange.com" Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 21:01:03 -0000 On 3/6/13 3:51 AM, Charles Eckel (eckelcu) wrote: >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Tuesday, March 05, 2013 10:29 AM >> To: Iñaki Baz Castillo >> Cc: dispatch@ietf.org; stephane.cazeaux@orange.com >> Subject: Re: [dispatch] Remapping existing protocols for web usage: >> websockets or data channels? >> >> Iñaki, >> >> In the specific case of bfcp, it is likely that one end will always be >> on a server. (Its unlikely that one would want to use bfcp in a pt-pt >> call between two web clients.) So that makes websockets suitable, where >> it would be less so for something that might be used between two web >> clients. > > I disagree, in that even in a pt to pt call, BFCP is used to negotiate which endpoint is allowed to transmit content. The offer/answer exchange is used to determine which end should be the BFCP server and which should be the BFCP client. In the case of a conference, the conference server typically tries to be the BFCP server and the conference participants happily let it. Good to have a comment from someone who actually knows about bfcp! In that case, websockets wouldn't work between two rtcweb clients without a relay in the middle, right? Thanks, Paul > Cheers, > Charles > >> >> My point in bringing up the question is so that we consider the >> pros/cons in the context of the likely alternatives. >> >> Thanks, >> Paul >> >> On 3/5/13 7:56 PM, Iñaki Baz Castillo wrote: >>> 2013/2/24 Paul Kyzivat : >>>> First, AFAIK there are currently no plans to put bfcp over a data channel, >>>> but I think there should be. >>>> >>>> My reason is because that is a mechanism that could be supported by a an >>>> RTCWEB client. And yes, it indeed may be the case that a CLUE endpoint >> may >>>> still need to support bfcp over tcp or udp for legacy interworking. >>>> >>>> It would also be possible for an RTCWEB clue client to use bfcp over a >>>> websocket. >>>> >>>> The question is: how many of these alternatives do we want to define >> and >>>> then ask people to support in their products. The more alternatives we >> have >>>> the less likely we are to get interoperability. >>> >>> >>> Hi, WebSocket is an already existing protocol implemented in both >>> clients (mostly web browsers) and servers (there are tons of WebSocket >>> server implementations). In the other side WebRTC Data Channel will be >>> first implemented as a direct communication mechanism between >> browsers >>> and, maybe in a future, there will appear *complex* server side >>> implementations (which all the SCTP-over-DTLS-over-UDP that Data >>> Channel requires). >>> >>> I don't know BFCP protocol but it seems to be a protocol to "manage a >>> conference server", am I right? If so, WebSocket protocol already >>> provides the pieces for carrying BFCP messages from WebSocket capable >>> clients to a WebSocket server. Doing the same with Data Channel will >>> require much more work. >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From sergio.garcia.murillo@gmail.com Tue Mar 5 13:27:31 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A7621F881D for ; Tue, 5 Mar 2013 13:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] 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 i1cDbuiZxXVJ for ; Tue, 5 Mar 2013 13:27:31 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D88E721F87FF for ; Tue, 5 Mar 2013 13:27:30 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u54so7124599wey.30 for ; Tue, 05 Mar 2013 13:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0mRd6mMTGMA4QimebwBl1aXqt4d8HcifoMqSSwbq1j8=; b=E84Wn/PG+eaMqTNte7xOfdHzujCLszQ125xUcDp+ewzH4IvJSXvgOpMkgUX3Ap3fh/ 6oz42Wc27Wu6BlQeVrIOI/RaP8gtH/XeKJFF77YGxaccnIROLXiqfL52c4oYUre8Sddi /3YOqSYQZtdg8Z7yl2PH1DGhUjVmsoYfDskc7sups0I2bouj0z4lMy2anpIgygyCXP5y KW1XbRj0sFLXvY9Zxlf1a2BFBuoyEJvExH4IIhHk9mqiz7TEbyPpMWX9cLyRua1vEmn2 jOMNpO+p5PEBKiK628H90F2VdhhyZCvlKB7w5x9J6tXCcwlzf5dBFMb6STesVcmbzGs4 mNLw== X-Received: by 10.194.57.137 with SMTP id i9mr21719025wjq.18.1362518850074; Tue, 05 Mar 2013 13:27:30 -0800 (PST) Received: from [192.168.1.2] (122.pool80-103-141.dynamic.orange.es. [80.103.141.122]) by mx.google.com with ESMTPS id ed6sm25305948wib.9.2013.03.05.13.27.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Mar 2013 13:27:28 -0800 (PST) Message-ID: <51366348.3080302@gmail.com> Date: Tue, 05 Mar 2013 22:27:36 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <5136397F.3000002@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828047C73EC@xmb-aln-x08.cisco.com> <51365D0D.80202@alum.mit.edu> In-Reply-To: <51365D0D.80202@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 21:27:31 -0000 El 05/03/2013 22:01, Paul Kyzivat escribió: > On 3/6/13 3:51 AM, Charles Eckel (eckelcu) wrote: >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Tuesday, March 05, 2013 10:29 AM >>> To: Iñaki Baz Castillo >>> Cc: dispatch@ietf.org; stephane.cazeaux@orange.com >>> Subject: Re: [dispatch] Remapping existing protocols for web usage: >>> websockets or data channels? >>> >>> Iñaki, >>> >>> In the specific case of bfcp, it is likely that one end will always be >>> on a server. (Its unlikely that one would want to use bfcp in a pt-pt >>> call between two web clients.) So that makes websockets suitable, where >>> it would be less so for something that might be used between two web >>> clients. >> >> I disagree, in that even in a pt to pt call, BFCP is used to >> negotiate which endpoint is allowed to transmit content. The >> offer/answer exchange is used to determine which end should be the >> BFCP server and which should be the BFCP client. In the case of a >> conference, the conference server typically tries to be the BFCP >> server and the conference participants happily let it. > > Good to have a comment from someone who actually knows about bfcp! > > In that case, websockets wouldn't work between two rtcweb clients > without a relay in the middle, right? But on the other side, if a browser doesn't support webrtc, you won't be able to use BFCP. Typical situation is when you are connecting to the conference simultaneously from a phone/videophone and also connected in your PC via web. Also, adding datachannels support to a server just to support BFCP on web clients is an absolute overkill. Best regards Sergio From ibc@aliax.net Tue Mar 5 13:54:40 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA321F86AD for ; Tue, 5 Mar 2013 13:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 MEdRPZre6dEh for ; Tue, 5 Mar 2013 13:54:40 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id DC60F21F8615 for ; Tue, 5 Mar 2013 13:54:39 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id ox1so6193489veb.41 for ; Tue, 05 Mar 2013 13:54:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=psRfQh1LgIwSRNzyecdXRXX6PLZqShW9vziFgm5ZHao=; b=fnzJ0rn2T0TqecSt101kqIFKWpImCqrycgBAR0Z+cFqdUAQcvHO4BzwNRLW9AuBFxw HOyWXQbtFtS8M0TU1sGpjycUYFZtiMObrp1H4xk1HjJu+IJ2HrlBhs+4eeNEELlckU+A +amF0lrTgiPbqf/NNiVIyyq/HyuoiLnBctXQNxGplQW8qaGkfn5Fx37blTD6CuX0Ftkv w9YjlvIkm+KKFVmW7VsJOk8K4IFgxp0aSYo57tAWpBK0QeRgM2Vy/M4CtwNKmLhhb+4v I/y6WWpunm6QhX2QwZG6EgJTsAO/87t1KTIWc8hzpM3yuiGD5i7PRB8NGI+OqreSBf8v 5WJQ== X-Received: by 10.52.26.209 with SMTP id n17mr8986852vdg.26.1362520478962; Tue, 05 Mar 2013 13:54:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.219.4 with HTTP; Tue, 5 Mar 2013 13:54:18 -0800 (PST) In-Reply-To: <51365D0D.80202@alum.mit.edu> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <5136397F.3000002@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828047C73EC@xmb-aln-x08.cisco.com> <51365D0D.80202@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 5 Mar 2013 22:54:18 +0100 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmqgeJRMrLOVqoLFJ8yLBxIsDwmqfVgZN3MvCKoAcZWHwYYirRjDk5q8UHv/UlPhtrnudRo Cc: "dispatch@ietf.org" , "stephane.cazeaux@orange.com" Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 21:54:40 -0000 2013/3/5 Paul Kyzivat : > In that case, websockets wouldn't work between two rtcweb clients without= a > relay in the middle, right? Right. WebSocket is client-server bi-directional communication. BTW I strongly consider an error assuming that a web application will run without knowledge of the web server from where the page was retrieved. A web application (let's name it "JavaScript application") is not like a standalone desktop app. Instead it plays the Web rules. WebRTC Data Channel aim is to provide a direct communication between browsers for those cases in which having the web server as intermediary is not a good idea (realtime applications like games, big file transfers and so on). But implementing a pure network protocol on top of Data Channel is not the "Web style" at all and website admins will like the idea because they loose the control. WebSocket requires server side so the website admin can "match" web logins and WebSocket connections if both are separate servers (via Cookies or whatever other well known Web mechanism). But in case Data Channels is used for direct communication between browsers then the server/provider/service is not aware of such a communication. That's not the Web model IMHO. My two cents. Best regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Mar 5 13:56:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327A321F8702 for ; Tue, 5 Mar 2013 13:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 21tko4sfXDaG for ; Tue, 5 Mar 2013 13:56:25 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id A194A21F86EC for ; Tue, 5 Mar 2013 13:56:25 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id fy7so4511492vcb.30 for ; Tue, 05 Mar 2013 13:56:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=gXAIT0Hl8bMgdZ5BNBV7sLk3aT4IoIk9eDKQ6r7cz5I=; b=g/Zxj/n1shLc0QgM2/FIq/NTdKvt1jvlyDwEIe0klRS70i3aQ8SVpnrsMKnAAeGJWz QfTOczmla1GnZ1UD86BfQrZ0qeO2kCBL0PVyF9WjQeE80E69MitxRQ7olHXO4pWNol20 9ukB0zdWKdl88QpHnUEc4JVwq0uDukdh2C8t9eKpBRBtbZJXBgIRUq8XS9CfzLVnEFPB 6t2TEY9xmcX1+d4PjS0lbGTJneUJWHrLFD+SFTP+jRR9ChteymAMYoPvBfu2qBC8DVM+ 7tJXCIki8DkUClKUid8/pEV75gTFxV/q+4igei+pKyNCcFYqXoRezqIYfeFPPXgYKzpC Jb4Q== X-Received: by 10.52.72.137 with SMTP id d9mr9018702vdv.105.1362520585067; Tue, 05 Mar 2013 13:56:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.219.4 with HTTP; Tue, 5 Mar 2013 13:56:03 -0800 (PST) In-Reply-To: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <5136397F.3000002@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828047C73EC@xmb-aln-x08.cisco.com> <51365D0D.80202@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 5 Mar 2013 22:56:03 +0100 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlv8I+wCCwiy93LimRkKfCQwh6/O+i+M1lwEB7lCXK4LtJVQMjIv0mn3Qp2igySK8eQmxE/ Cc: "dispatch@ietf.org" , "stephane.cazeaux@orange.com" Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 21:56:26 -0000 2013/3/5 I=C3=B1aki Baz Castillo : > and website admins will like the idea > because they loose the control. I mean: "the WON'T like the idea". --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Tue Mar 5 14:28:40 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6D621F8653 for ; Tue, 5 Mar 2013 14:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.084 X-Spam-Level: X-Spam-Status: No, score=-0.084 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 PnhKo1Dc0qKb for ; Tue, 5 Mar 2013 14:28:39 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 9215D21F8650 for ; Tue, 5 Mar 2013 14:28:39 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id 7uEE1l00G1swQuc55yUfDb; Tue, 05 Mar 2013 22:28:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id 7yUe1l01N3ZTu2S3byUeeK; Tue, 05 Mar 2013 22:28:39 +0000 Message-ID: <51367196.8090204@alum.mit.edu> Date: Wed, 06 Mar 2013 06:28:38 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <5136397F.3000002@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828047C73EC@xmb-aln-x08.cisco.com> <51365D0D.80202@alum.mit.edu> <51366348.3080302@gmail.com> In-Reply-To: <51366348.3080302@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362522519; bh=WCzvVoTn60Ij4BeQxdzMX3cQIWtnPoBWNVZ4QN9GQEY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tOJdL+o2HoE6dlICU3dTwOq0ptaid6a68Zd3zNumT8sv4dtvOa2uQtWfrhiwM7cyR oVJWVL7BBG1wm0j9GDq2mJyY8yXJsrni8e2TgRw2jetxINRLcqLMM3AAsLuvg5i7mh 7iG3rVykfloJ6xcUP6MvT67/QQAHG3W6Gls1KIYweDjJthUBxzuYKy02iRfFCx28tC y54sDFP1pkMOeHyVW8xxT9qySy/e+7Y4ze4Qa31FjA84mMo7mTIdRQTxlgDfOiwa6e EuZ2h4YZ7PWYcqkCFYt1w277YlkIKCbWUyhL8giT1OsVjp7/O8CSck8OQh4VE9+NZI nogjeVpqYFEjA== Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 22:28:40 -0000 On 3/6/13 5:27 AM, Sergio Garcia Murillo wrote: > El 05/03/2013 22:01, Paul Kyzivat escribió: >> On 3/6/13 3:51 AM, Charles Eckel (eckelcu) wrote: >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Tuesday, March 05, 2013 10:29 AM >>>> To: Iñaki Baz Castillo >>>> Cc: dispatch@ietf.org; stephane.cazeaux@orange.com >>>> Subject: Re: [dispatch] Remapping existing protocols for web usage: >>>> websockets or data channels? >>>> >>>> Iñaki, >>>> >>>> In the specific case of bfcp, it is likely that one end will always be >>>> on a server. (Its unlikely that one would want to use bfcp in a pt-pt >>>> call between two web clients.) So that makes websockets suitable, where >>>> it would be less so for something that might be used between two web >>>> clients. >>> >>> I disagree, in that even in a pt to pt call, BFCP is used to >>> negotiate which endpoint is allowed to transmit content. The >>> offer/answer exchange is used to determine which end should be the >>> BFCP server and which should be the BFCP client. In the case of a >>> conference, the conference server typically tries to be the BFCP >>> server and the conference participants happily let it. >> >> Good to have a comment from someone who actually knows about bfcp! >> >> In that case, websockets wouldn't work between two rtcweb clients >> without a relay in the middle, right? > > But on the other side, if a browser doesn't support webrtc, you won't be > able to use BFCP. Typical situation is when you are connecting to the > conference simultaneously from a phone/videophone and also connected in > your PC via web. > > Also, adding datachannels support to a server just to support BFCP on > web clients is an absolute overkill. What are we trying to accomplish here? If we want to support use of BFCP by an RTCWEB client, then presumably the browser supporting that client supports RTCWEB. So it could use BFCP over data channel. Or we could use websocket. If we want to support a web client that is not an RTCWEB client, and running with a web browser that doesn't support RTCWEB, then we could use BFCP over websocket. But then two of those couldn't talk to one another - they could only talk to a server. That would work with conference servers that support BFCP over websocket. The main impact seems to be whether the server prefers to support websocket or data channel for BFCP. Maybe it would be a bit easier. But some will be doing data channels anyway. (E.g. for CLUE.) Thanks, Paul From pkyzivat@alum.mit.edu Tue Mar 5 14:43:21 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAB711E8123 for ; Tue, 5 Mar 2013 14:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.045 X-Spam-Level: X-Spam-Status: No, score=0.045 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 uvB2ITn7czea for ; Tue, 5 Mar 2013 14:43:20 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 96DB311E8118 for ; Tue, 5 Mar 2013 14:43:20 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta09.westchester.pa.mail.comcast.net with comcast id 7qT31l0031uE5Es59yjA2Q; Tue, 05 Mar 2013 22:43:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id 7yjA1l00Q3ZTu2S3cyjAvr; Tue, 05 Mar 2013 22:43:10 +0000 Message-ID: <513674FD.3070704@alum.mit.edu> Date: Wed, 06 Mar 2013 06:43:09 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <5136397F.3000002@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828047C73EC@xmb-aln-x08.cisco.com> <51365D0D.80202@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362523390; bh=aOvOopDhco34KiutA/3txtBsxwUrdVyBdyML8uqjPUA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hpvbHTRPfne3tH/JEjez5eNDcTSTn6zm4zVrQ56v+Fod5gcw0fsUYpcdvxnIS+JcP Gcn2gkJD8jm0zv1ESz235jwZ85635ReRtVDvo9B3LfPevra3s2f8NBePPBOtACbGOW azz4uMlQZJPxyJK5dDZg087bC8wmgiTWtTPvvGJ0e8j984PfyqJDSb87sbPTQC/hse OK7lZlEABjulqr6ZZKlDKoQbCWW5CYXZDFs3qsBMqkdA9VWxpGATCZsHI22xJigG/e 9T0YYPuHxNif6j0GwCrW0FZxV6qOv0N77WmIPdMHPpMFHpexIW7htStEEPb61uu1N3 zMIRSN43uF3Vw== Cc: "dispatch@ietf.org" , "stephane.cazeaux@orange.com" Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 22:43:21 -0000 On 3/6/13 5:54 AM, Iñaki Baz Castillo wrote: > 2013/3/5 Paul Kyzivat : >> In that case, websockets wouldn't work between two rtcweb clients without a >> relay in the middle, right? > > Right. WebSocket is client-server bi-directional communication. > > BTW I strongly consider an error assuming that a web application will > run without knowledge of the web server from where the page was > retrieved. > > A web application (let's name it "JavaScript application") is not like > a standalone desktop app. Instead it plays the Web rules. WebRTC Data > Channel aim is to provide a direct communication between browsers for > those cases in which having the web server as intermediary is not a > good idea (realtime applications like games, big file transfers and so > on). But implementing a pure network protocol on top of Data Channel > is not the "Web style" at all and website admins will like the idea > because they loose the control. > > WebSocket requires server side so the website admin can "match" web > logins and WebSocket connections if both are separate servers (via > Cookies or whatever other well known Web mechanism). But in case Data > Channels is used for direct communication between browsers then the > server/provider/service is not aware of such a communication. That's > not the Web model IMHO. This is not something I know a lot about, so I'd like to hear from others who do. There are two different use cases here: - endpoints talking to each other, pt-pt - endpoints talking to a conference server When web endpoints are involved, there is also a web server for each of those. (It may be the same one, or not.) And there can be mixed cases where one endpoint is a web client and the other is not. When there is a conference server, it may be the same, or affiliated with, a web server that services the web clients. In that case it might be quite natural for BFCP over websocket to terminate on that web server and be directly coupled to the conference server. But it is also possible that there is a pt-pt call between two endpoints who want to do floor control among themselves, as Charles described. (I have no idea if this happens much in practice.) If so, then requiring a web server to mediate over the BFCP is problematic. And its also possible that we have a conference server that knows nothing of the web. And then a separate web server that provides an RTCWEB gateway to calls and conferences. Do we want it to be involved in the BFCP? I don't think so. Except in the case where the web server is coupled to the conference server I can see no rationale for the web server to be aware of the BFCP. Thanks, Paul From ibc@aliax.net Wed Mar 6 09:01:04 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D6421F8C2A for ; Wed, 6 Mar 2013 09:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 SlfK1cFlRx0t for ; Wed, 6 Mar 2013 09:01:04 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3C35F21F89C0 for ; Wed, 6 Mar 2013 09:01:04 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so1536830qcs.27 for ; Wed, 06 Mar 2013 09:01:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=9/YBvP3CHfsC1dvmxzSWeJdquXCE8XMXNoqbn6vQs8Y=; b=DWoVco8GgoJ3A1qqX1J4KJ++jYLDX3BVQ2xCs37QV2XTfvdPR/wmi9IgZOjUdhM6j3 mjGfVl3S63gi3LugB6DELzRk3JFDuC7sbizSTf1RUtRatL2DbEh3hAIy00VGZuy8hPT3 4U8PRQAJQt5Izf5s12wbqnL6PXy5pd56wlj/dsHQccOGBGvkrXJTvQy0KBnzqmgLBXms hdODATT+caLr5bLMRCqIRq5EsxMHcVR55eYhJDwdcikDbh44M2hNDzy4wRmTnDD/f6Db AkcYOMe0X12dnDsclb724jAXmefvgAoPoaxcY4xciyJiAal/Uf8x8yGkcwrmOLrvIHcc 12zQ== X-Received: by 10.229.196.86 with SMTP id ef22mr8204921qcb.155.1362589259767; Wed, 06 Mar 2013 09:00:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.12.233 with HTTP; Wed, 6 Mar 2013 09:00:39 -0800 (PST) In-Reply-To: <51348999.1000506@gmail.com> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 6 Mar 2013 18:00:39 +0100 Message-ID: To: Sergio Garcia Murillo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnrcS/heYF28+NUs1bKRRfHlRVEi4jxyv6AtxelletUVkh2z8JzZh2tSQEK6eokDYmxEh/8 Cc: dispatch@ietf.org, stephane.cazeaux@orange.com Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:01:04 -0000 2013/3/4 Sergio Garcia Murillo : > So, as in our case, we will be implementing bcfp over websockets in any c= ase > to support this html interface, it would be great to be able to reuse the > same implementation for webrtc clients (i.e exchanging the set up > information in the sdp), and avoid the costs of implementing datachannels= at > all. I don't know BCFP, but by looking at SDP examples in RFC 4583 I see this: --------------- m=3Dapplication 50000 TCP/TLS/BFCP * a=3Dsetup:passive a=3Dconnection:new a=3Dfingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=3Dfloorctrl:s-only a=3Dconfid:4321 a=3Duserid:1234 a=3Dfloorid:1 m-stream:10 a=3Dfloorid:2 m-stream:11 m=3Daudio 50002 RTP/AVP 0 a=3Dlabel:10 m=3Dvideo 50004 RTP/AVP 31 a=3Dlabel:11 --------------- Well, I strongly hope nobody plans to pass such an SDP to a WebRTC RTCPeerConnection constructor since it will die. This is, I hope running BCFP does not require sending an INVITE with SDP containing both audio/video data and BCFP data, because that will never work in WebRTC land, and playing with JavaScript for parsing, splitting and merging SDP fragments is not funny at all. > Also, as a side discussion, regardless of the transport chosen, I don't s= ee > managing binary messages in the browser is something natural, if possible= , > it would be a good idea to add support for other serialization formats fo= r > bcfp messages more usable in browsers (i.e. json or xml). WebSocket allows both UTF-8 and binary WebSocket messages. How the JS client code (in the web application) handles binary data is up to the developer, but JavaScript is not "byte aware" at all, so probably this is a show-stopper. What I mean is that, prior to starting a work for standarizing BCFP over WebSocket or over WebRTC Data Channel, it's required to verify whether the *binary* data carried on top of the transport is manageable, OR NOT, by a JS application. I insist: JavaScript knows about unicode symbols, not about bytes. I may miss something, of course. Regards. --=20 I=C3=B1aki Baz Castillo From stpeter@stpeter.im Wed Mar 6 12:52:57 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EA121F89D2 for ; Wed, 6 Mar 2013 12:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.253 X-Spam-Level: X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 GiS3Yn+IH19B for ; Wed, 6 Mar 2013 12:52:51 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9466121F88D1 for ; Wed, 6 Mar 2013 12:52:48 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BDDAB4004E; Wed, 6 Mar 2013 14:01:01 -0700 (MST) Message-ID: <5137AC9E.5080608@stpeter.im> Date: Wed, 06 Mar 2013 13:52:46 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Richard Barnes , DISPATCH , "rai-ads@tools.ietf.org" Subject: Re: [dispatch] IETF-86 DISPATCH Topics X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 20:52:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/27/13 3:53 PM, Mary Barnes wrote: > Topics to be discussed at IETF-86: 1) SIP/XMPP Interworking: > http://www.ietf.org/mail-archive/web/dispatch/current/msg04561.html Thanks. > I have uploaded some slides for that topic here: https://stpeter.im/files/ietf86-dispatch-sip-xmpp.pdf I will let the chairs know if I make any changes to those slides before the end of the week (if not, they can be considered final). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRN6ydAAoJEOoGpJErxa2pEbwP/RLXZYH3HZNWPBXf08bwWKRY mWMFbEKWZiRla1UKzFHFbHX4HFaKm8CwkeQ9t2mynQIZNkBC27BWLkBg577KQStP VDH5F6Y4EmHdiuPMIqDW2GmSHAkZZCmbR1L6hUneUigzF99Zv/QMxcgq0fQ13POb 6PxJSPbnH8Ier1SUjIfg74WqciPoEynJJgGJ4pgOjUfzRPrr7tedW52S5eEIzX+a L0hvzL3VMX/Z34aSZ9obamAcXxxbO8UhchP8uHcbrPm2S4dRAbrnz9SeFgAG2rOu fyQIGVnGmBMasGh6vmFTrKyJp6PojEw8SAOSA4BIlT6RWO8iPRzcxE7j3RAMyGt2 i7LdsrkxjWpy7eZZi+ULQ7RaYh3+JKV6zBLdj2cJM2ARc2+luPWZIXS+TUkjYjpu zFZZjeMyVVZ0Z7hUAH+ddfCbg9xcxoU5GnhdUY/clmerVCTe7zvE1wlv+iKQ4YZV sXogzC7zrw9HdquXbrk3moivbO7MAOVv69AiWJ6SaRF1b2ZvqqDnBGq2tvBM4Adl ncPReGs8z7fj9y0x4TrQ4ZI8ioKvpbFeY1OVH+PB8pPS7idb+Dm64MdWtogUTy9+ 1h29TAcZnIGQBi0o4gKcGQ/0d37hpONcrgeLZWVyfVYECFRVF09uVlSfM2SQ4HPY 7yFbBqIkppHkkCXKtDMN =Wc9b -----END PGP SIGNATURE----- From mary.ietf.barnes@gmail.com Thu Mar 7 06:22:15 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709D321F8D03 for ; Thu, 7 Mar 2013 06:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.761 X-Spam-Level: X-Spam-Status: No, score=-103.761 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 wMO7bUWqzO7D for ; Thu, 7 Mar 2013 06:22:14 -0800 (PST) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 98E2921F87D7 for ; Thu, 7 Mar 2013 06:22:12 -0800 (PST) Received: by mail-qe0-f45.google.com with SMTP id b4so283638qen.32 for ; Thu, 07 Mar 2013 06:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JtNQsFdR6BFb9K9jd/BYomnZ5ezjEUwe4e1QWgZcIaY=; b=Wziwset1qsQmA5XFzvz9c9TcYYPsyGTvccqXZXi8sNPX2Qe9rt3RP+ayG73pGSueT0 Mn7Fhr5EYVcqLOgT0MfuqoL2nm1k8Doqd8fqvvKX4GpP//GG1KpCTdNmKLCVS+ctRuMy 4GVkFsZrbsIu6JLA27BioPBSEKkU56pqC890g+CiVPccoC9PVB/pb0KYBpW3S2WlZBg9 jeSHL53ycUlHYsAEWZAnCqm026G983l7CBoRBQN0kA7dFyO7tiz3dAuZJjErIOLXKYbL EMIigQmu6MB98HyITVtOBnOY4u6KD7L/sje2Nu5epvUf5UdyYToZs3TE5fv4bPT0kBGv tXFQ== MIME-Version: 1.0 X-Received: by 10.49.85.34 with SMTP id e2mr55849403qez.1.1362666132132; Thu, 07 Mar 2013 06:22:12 -0800 (PST) Received: by 10.49.24.130 with HTTP; Thu, 7 Mar 2013 06:22:12 -0800 (PST) In-Reply-To: <5137AC9E.5080608@stpeter.im> References: <5137AC9E.5080608@stpeter.im> Date: Thu, 7 Mar 2013 08:22:12 -0600 Message-ID: From: Mary Barnes To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , Richard Barnes , DISPATCH , "rai-ads@tools.ietf.org" Subject: Re: [dispatch] IETF-86 DISPATCH Topics X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 14:22:15 -0000 Peter, Thank you very much! I have uploaded to the proceedings: https://datatracker.ietf.org/meeting/86/materials.html Just let us know if you do make any changes so we can make sure and have the right version available. Mary. On Wed, Mar 6, 2013 at 2:52 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/27/13 3:53 PM, Mary Barnes wrote: > >> Topics to be discussed at IETF-86: 1) SIP/XMPP Interworking: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg04561.html > > Thanks. >> > I have uploaded some slides for that topic here: > > https://stpeter.im/files/ietf86-dispatch-sip-xmpp.pdf > > I will let the chairs know if I make any changes to those slides > before the end of the week (if not, they can be considered final). > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRN6ydAAoJEOoGpJErxa2pEbwP/RLXZYH3HZNWPBXf08bwWKRY > mWMFbEKWZiRla1UKzFHFbHX4HFaKm8CwkeQ9t2mynQIZNkBC27BWLkBg577KQStP > VDH5F6Y4EmHdiuPMIqDW2GmSHAkZZCmbR1L6hUneUigzF99Zv/QMxcgq0fQ13POb > 6PxJSPbnH8Ier1SUjIfg74WqciPoEynJJgGJ4pgOjUfzRPrr7tedW52S5eEIzX+a > L0hvzL3VMX/Z34aSZ9obamAcXxxbO8UhchP8uHcbrPm2S4dRAbrnz9SeFgAG2rOu > fyQIGVnGmBMasGh6vmFTrKyJp6PojEw8SAOSA4BIlT6RWO8iPRzcxE7j3RAMyGt2 > i7LdsrkxjWpy7eZZi+ULQ7RaYh3+JKV6zBLdj2cJM2ARc2+luPWZIXS+TUkjYjpu > zFZZjeMyVVZ0Z7hUAH+ddfCbg9xcxoU5GnhdUY/clmerVCTe7zvE1wlv+iKQ4YZV > sXogzC7zrw9HdquXbrk3moivbO7MAOVv69AiWJ6SaRF1b2ZvqqDnBGq2tvBM4Adl > ncPReGs8z7fj9y0x4TrQ4ZI8ioKvpbFeY1OVH+PB8pPS7idb+Dm64MdWtogUTy9+ > 1h29TAcZnIGQBi0o4gKcGQ/0d37hpONcrgeLZWVyfVYECFRVF09uVlSfM2SQ4HPY > 7yFbBqIkppHkkCXKtDMN > =Wc9b > -----END PGP SIGNATURE----- From peter.dunkley@crocodile-rcs.com Thu Mar 7 07:43:51 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C531D21F8D9A for ; Thu, 7 Mar 2013 07:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 N80O6pqks4wk for ; Thu, 7 Mar 2013 07:43:49 -0800 (PST) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id A874621F8D92 for ; Thu, 7 Mar 2013 07:43:47 -0800 (PST) Received: (qmail 27541 invoked by uid 0); 7 Mar 2013 15:43:22 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy13.unifiedlayer.com with SMTP; 7 Mar 2013 15:43:22 -0000 Received: from [90.152.0.102] (port=46394 helo=[192.168.0.156]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UDcyY-000849-3e; Thu, 07 Mar 2013 08:43:22 -0700 Message-ID: <5138B593.9060802@crocodile-rcs.com> Date: Thu, 07 Mar 2013 15:43:15 +0000 From: Peter Dunkley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with peter.dunkley@crocodile-rcs.com} Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 15:43:51 -0000 Hello Ben, I am sorry it took a while to respond to your comments. I wanted to confer with my colleague Gavin Llewellyn (who has been on vacation) before responding. My comments are in-line below. Regards, Peter On 21/02/13 22:23, Ben Campbell wrote: > ** Major: > > -- General: Interworking with legacy relays and endpoints: > > I infer that an MSRP WebSocket Server is expected to also act as an ordinary MSRP relay, in that it can talk to legacy relays and clients. Is there a normative requirement for that that I missed? Is it allowed to have an MSRP WebSocket server that only enables communication between WebSocket Clients? This draft extends RFC4975 and RFC4976 and is intended to increase the capabilities of MSRP clients and relays not reduce it. There is no practical reason to not allow MSRP WebSocket servers to only communicate between WebSocket clients, but that is deliberately not an aspect that this draft considers. The intention of this draft is to enable MSRP over WebSocket clients to be used in addition to (and with) current MSRP clients. > -- Use of TLS: > > I'm very concerned about downgrading the 4976 MUST on use of TLS between a client and a relay that it authenticates to. This seems unacceptable on it's face. You indicate that the client code may have no control over this--can you elaborate? In a Javascript client running in a browser you can mandate TLS by using a wss:// URL. However: 1) You cannot force mutual TLS or any extended verification - you are stuck with what the browser does 2) Self-signed certificates and certificates where domain-names/addresses do not match are handled badly by browser WebSocket implementations Point 1 means that you will never get the level of security and assurance with TLS for WebSockets that RFC 4976 gives you for ordinary MSRP clients. Point 2: for HTTP you have things like the Firefox add exception dialog (or IE/Chrome warning about the certificate page) to help you with locally defined certificates. There is no such thing for WebSockets and no obvious way of adding it. This means that unless you have specifically configured each computer to accept the certificate the connection establishment will fail. Properly signed certificates used on the Internet will be no problem, but this is a show-stopper if you have a large internal deployment. Because of these points I felt that, while people should be encouraged to be as secure as possible, the use of TLS in this case needs to be a matter of local policy. Leaving the strong requirements of RFC 4976 in place here would result in either a specification that could not be implemented at all, or was simply impractical for many deployments. It should be noted that the TLS requirements are downgraded only for the situation where WebSockets are used. This change does not affect non-WebSocket MSRP relay connections. > ** Minor: > > -- 5.1: > > Be careful with the terminology. In MSRP, a "message" means the pre-chunked content. If you split it, each piece is a "chunk". I think you mean to say that each WebSocket message must contain a single MSRP "chunk", correct? Yes. I will look at updating the terminology in the next draft. > Also, are there issues with large chunks? Does the MSRP concept of starting to send large content in a single chunk, but interrupting it if needed work with WebSockets? WebSocket sends messages in frames. It is possible to have a multi-frame WebSocket message, but doing so is complex and some implementations do not fully support this. As such it makes sense to mandate that a chunk sent using MSRP over WebSocket fits within a single WebSocket frame. This places a requirement on an MSRP over WebSocket client to chunk large data-sets. It also places a requirement on an MSRP over WebSocket server (which may receive large content from non-WebSocket clients) to chunk messages to WebSocket clients. > -- 7: > > Can you offer guidance on what should happen if a server tries to use HTTP Digest at the MSRP layer, but the client doesn't support it? (The reciprocal of "MAY" us usually "MUST". That is, if a device MAY do something, the peer MUST gracefully handle it.) I can foresee a number of scenarios where WebSocket handshake authentication will be sufficient. It is entirely possible to develop an MSRP WebSocket client or MSRP WebSocket server that is intended for use in just these scenarios. As a result I did not want to mandate any unnecessary implementation just so that a client can be said to adhere to this specification. Perhaps some slightly different language would be appropriate here? Does anyone have any suggestions? > -- 9.1: > > I'd like to see some guidance about server certificate matching. Do the rules in 4976 and 4975 still apply? Due to the way the browser/Javascript WebSocket APIs work they cannot still apply. This is why the TLS requirement was loosened in section 5.3.2 From oej@edvina.net Thu Mar 7 08:31:47 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6014721F8B1D for ; Thu, 7 Mar 2013 08:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 sT7fLzIbLwvw for ; Thu, 7 Mar 2013 08:31:46 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 136FB21F8D29 for ; Thu, 7 Mar 2013 08:31:46 -0800 (PST) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 70BD993DE3C; Thu, 7 Mar 2013 16:31:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <5138B593.9060802@crocodile-rcs.com> Date: Thu, 7 Mar 2013 17:31:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <950956C8-EF2A-412A-9941-0975DD73F10A@edvina.net> References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <5138B593.9060802@crocodile-rcs.com> To: Peter Dunkley X-Mailer: Apple Mail (2.1499) Cc: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 16:31:47 -0000 7 mar 2013 kl. 16:43 skrev Peter Dunkley = : >=20 > Hello Ben, >=20 > I am sorry it took a while to respond to your comments. I wanted to = confer with my colleague Gavin Llewellyn (who has been on vacation) = before responding. >=20 > My comments are in-line below. >=20 > Regards, >=20 > Peter >=20 > On 21/02/13 22:23, Ben Campbell wrote: >> ** Major: >>=20 >> -- General: Interworking with legacy relays and endpoints: >>=20 >> I infer that an MSRP WebSocket Server is expected to also act as an = ordinary MSRP relay, in that it can talk to legacy relays and clients. = Is there a normative requirement for that that I missed? Is it allowed = to have an MSRP WebSocket server that only enables communication between = WebSocket Clients? > This draft extends RFC4975 and RFC4976 and is intended to increase the = capabilities of MSRP clients and relays not reduce it. >=20 > There is no practical reason to not allow MSRP WebSocket servers to = only communicate between WebSocket clients, but that is deliberately not = an aspect that this draft considers. The intention of this draft is to = enable MSRP over WebSocket clients to be used in addition to (and with) = current MSRP clients. >=20 >> -- Use of TLS: >>=20 >> I'm very concerned about downgrading the 4976 MUST on use of TLS = between a client and a relay that it authenticates to. This seems = unacceptable on it's face. You indicate that the client code may have no = control over this--can you elaborate? > In a Javascript client running in a browser you can mandate TLS by = using a wss:// URL. However: > 1) You cannot force mutual TLS or any extended verification - you are = stuck with what the browser does > 2) Self-signed certificates and certificates where = domain-names/addresses do not match are handled badly by browser = WebSocket implementations >=20 > Point 1 means that you will never get the level of security and = assurance with TLS for WebSockets that RFC 4976 gives you for ordinary = MSRP clients. >=20 > Point 2: for HTTP you have things like the Firefox add exception = dialog (or IE/Chrome warning about the certificate page) to help you = with locally defined certificates. There is no such thing for = WebSockets and no obvious way of adding it. This means that unless you = have specifically configured each computer to accept the certificate the = connection establishment will fail. Properly signed certificates used = on the Internet will be no problem, but this is a show-stopper if you = have a large internal deployment. >=20 > Because of these points I felt that, while people should be encouraged = to be as secure as possible, the use of TLS in this case needs to be a = matter of local policy. Leaving the strong requirements of RFC 4976 in = place here would result in either a specification that could not be = implemented at all, or was simply impractical for many deployments. >=20 > It should be noted that the TLS requirements are downgraded only for = the situation where WebSockets are used. This change does not affect = non-WebSocket MSRP relay connections. That the current browser implementation sucks in error handling for = websockets is not a reason to lower the bar in the draft. We've = successfully raised the bar in regards of security in WebRTC and I hope = we can keep the bar high here too. The problem with the wss implementations was shown at SIPit. Hopefully = it's on the participating browser developer's todo list. If not, it = should be reported in their bug trackers. It was embarrassing that a = javascript app developer couldn't get a proper error code for expired = certs or other TLS connection failures. /O >=20 >> ** Minor: >>=20 >> -- 5.1: >>=20 >> Be careful with the terminology. In MSRP, a "message" means the = pre-chunked content. If you split it, each piece is a "chunk". I think = you mean to say that each WebSocket message must contain a single MSRP = "chunk", correct? > Yes. I will look at updating the terminology in the next draft. >=20 >> Also, are there issues with large chunks? Does the MSRP concept of = starting to send large content in a single chunk, but interrupting it if = needed work with WebSockets? > WebSocket sends messages in frames. It is possible to have a = multi-frame WebSocket message, but doing so is complex and some = implementations do not fully support this. As such it makes sense to = mandate that a chunk sent using MSRP over WebSocket fits within a single = WebSocket frame. This places a requirement on an MSRP over WebSocket = client to chunk large data-sets. It also places a requirement on an = MSRP over WebSocket server (which may receive large content from = non-WebSocket clients) to chunk messages to WebSocket clients. >=20 >> -- 7: >>=20 >> Can you offer guidance on what should happen if a server tries to use = HTTP Digest at the MSRP layer, but the client doesn't support it? (The = reciprocal of "MAY" us usually "MUST". That is, if a device MAY do = something, the peer MUST gracefully handle it.) > I can foresee a number of scenarios where WebSocket handshake = authentication will be sufficient. It is entirely possible to develop = an MSRP WebSocket client or MSRP WebSocket server that is intended for = use in just these scenarios. As a result I did not want to mandate any = unnecessary implementation just so that a client can be said to adhere = to this specification. >=20 > Perhaps some slightly different language would be appropriate here? = Does anyone have any suggestions? >=20 >> -- 9.1: >>=20 >> I'd like to see some guidance about server certificate matching. Do = the rules in 4976 and 4975 still apply? > Due to the way the browser/Javascript WebSocket APIs work they cannot = still apply. This is why the TLS requirement was loosened in section = 5.3.2 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From peter.dunkley@crocodile-rcs.com Thu Mar 7 08:50:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079CD21F8A4A for ; Thu, 7 Mar 2013 08:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 MNvIw3KFbPIG for ; Thu, 7 Mar 2013 08:50:52 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 6886321F8A43 for ; Thu, 7 Mar 2013 08:50:49 -0800 (PST) Received: (qmail 7685 invoked by uid 0); 7 Mar 2013 16:50:28 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by cpoproxy3.bluehost.com with SMTP; 7 Mar 2013 16:50:28 -0000 Received: from [90.152.0.102] (port=46967 helo=[192.168.0.156]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UDe1T-0000gv-U0; Thu, 07 Mar 2013 09:50:28 -0700 Message-ID: <5138C54D.601@crocodile-rcs.com> Date: Thu, 07 Mar 2013 16:50:21 +0000 From: Peter Dunkley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Olle E. Johansson" References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <5138B593.9060802@crocodile-rcs.com> <950956C8-EF2A-412A-9941-0975DD73F10A@edvina.net> In-Reply-To: <950956C8-EF2A-412A-9941-0975DD73F10A@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with peter.dunkley@crocodile-rcs.com} Cc: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 16:50:53 -0000 >>> -- Use of TLS: >>> >>> I'm very concerned about downgrading the 4976 MUST on use of TLS between a client and a relay that it authenticates to. This seems unacceptable on it's face. You indicate that the client code may have no control over this--can you elaborate? >> In a Javascript client running in a browser you can mandate TLS by using a wss:// URL. However: >> 1) You cannot force mutual TLS or any extended verification - you are stuck with what the browser does >> 2) Self-signed certificates and certificates where domain-names/addresses do not match are handled badly by browser WebSocket implementations >> >> Point 1 means that you will never get the level of security and assurance with TLS for WebSockets that RFC 4976 gives you for ordinary MSRP clients. >> >> Point 2: for HTTP you have things like the Firefox add exception dialog (or IE/Chrome warning about the certificate page) to help you with locally defined certificates. There is no such thing for WebSockets and no obvious way of adding it. This means that unless you have specifically configured each computer to accept the certificate the connection establishment will fail. Properly signed certificates used on the Internet will be no problem, but this is a show-stopper if you have a large internal deployment. >> >> Because of these points I felt that, while people should be encouraged to be as secure as possible, the use of TLS in this case needs to be a matter of local policy. Leaving the strong requirements of RFC 4976 in place here would result in either a specification that could not be implemented at all, or was simply impractical for many deployments. >> >> It should be noted that the TLS requirements are downgraded only for the situation where WebSockets are used. This change does not affect non-WebSocket MSRP relay connections. > That the current browser implementation sucks in error handling for websockets is not a reason to lower the bar in the draft. We've successfully raised the bar in regards of security in WebRTC and I hope we can keep the bar high here too. > > The problem with the wss implementations was shown at SIPit. Hopefully it's on the participating browser developer's todo list. If not, it should be reported in their bug trackers. It was embarrassing that a javascript app developer couldn't get a proper error code for expired certs or other TLS connection failures. > > /O > Hi Olle, This deals with my point 2 (assuming the browser developers do fix the problems), but it really doesn't help with point 1. Making it possible to do this level of extended TLS security for WebSockets in a web-browser is surely well outside of something the IETF can do alone? After all, it is the W3C that specify the Javascript APIs for managing WebSocket connections and these would require significant re-work to support this. I'm all for making things as secure as possible, but I can't see this level of security being achievable from a browser any-time soon. Regards, Peter From pkyzivat@alum.mit.edu Thu Mar 7 09:01:43 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0BE21F8A0C for ; Thu, 7 Mar 2013 09:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.378 X-Spam-Level: X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] 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 sjYMwYoxr2Gr for ; Thu, 7 Mar 2013 09:01:43 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id E2FFA21F89C7 for ; Thu, 7 Mar 2013 09:01:29 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id 8bUe1l0021GhbT851h1V9Q; Thu, 07 Mar 2013 17:01:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id 8h1U1l01H3ZTu2S3Th1VNL; Thu, 07 Mar 2013 17:01:29 +0000 Message-ID: <5138C7E8.1090002@alum.mit.edu> Date: Fri, 08 Mar 2013 01:01:28 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362675689; bh=u+4yg7sytMbkkq0ti9SmcLtCqEEai5lmwgjzB8+ar4s=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kWUvb05w9U8G1s171g6Y7d7u/4qUWMY3KHoqTyUUwTLdR3S4nrxuCF2C4Q8nEBKMb DUwsK+tWSIb1z3Q8Qd005k0K32n0zVdJF019/NntiBWg56qkianRK2dJNBMPS7bbtX dfOlUre5eJdU9lK0vCkuhFDeOj6P+3p+ou6fgtL4wGotaHlxCZ7+ud96AeKAlJ21wH EFiFA7fed1HK9mKuCpivZ2yGxHVBCB+5bgsk/GmggRUv1lNwOI+vapr1cYk8dwpDGf Y2XlPJ/K+8Q65Ga7Xr/IDYdkSR1X+yoYNrgQx03RjRZ2TnnWVnRD6mMH0bWjYfBEnT j2MqBHEQGnMAQ== Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 17:01:43 -0000 Iñaki, Yes, IIUC the existing BFCP can't be used from a browser - neither the TCP nor the UDP form. And that won't be fixed by webrtc. So what to do about that? It appears there are three possibilities: 1) A new mapping of BFCP over websockets 2) A new mapping of BFCP over webrtc data channel 3) build a BFCP "proxy" in the web server, converting to proprietary signaling between the web server and the browser. Hopefully we can discard (3) as unreasonable. It sounds like (2) will be more secure unless some improvements are made to websockets. And (2) will work when doing BFCP pt-pt between two browsers, where (1) won't without some sort of proxy in the middle. OTOH (1) may be easier to implement when the other end is a server rather than a browser. Thanks, Paul On 3/7/13 1:00 AM, Iñaki Baz Castillo wrote: > 2013/3/4 Sergio Garcia Murillo : >> So, as in our case, we will be implementing bcfp over websockets in any case >> to support this html interface, it would be great to be able to reuse the >> same implementation for webrtc clients (i.e exchanging the set up >> information in the sdp), and avoid the costs of implementing datachannels at >> all. > > I don't know BCFP, but by looking at SDP examples in RFC 4583 I see this: > > --------------- > m=application 50000 TCP/TLS/BFCP * > a=setup:passive > a=connection:new > a=fingerprint:SHA-1 \ > 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB > a=floorctrl:s-only > a=confid:4321 > a=userid:1234 > a=floorid:1 m-stream:10 > a=floorid:2 m-stream:11 > m=audio 50002 RTP/AVP 0 > a=label:10 > m=video 50004 RTP/AVP 31 > a=label:11 > --------------- > > Well, I strongly hope nobody plans to pass such an SDP to a WebRTC > RTCPeerConnection constructor since it will die. This is, I hope > running BCFP does not require sending an INVITE with SDP containing > both audio/video data and BCFP data, because that will never work in > WebRTC land, and playing with JavaScript for parsing, splitting and > merging SDP fragments is not funny at all. > > > >> Also, as a side discussion, regardless of the transport chosen, I don't see >> managing binary messages in the browser is something natural, if possible, >> it would be a good idea to add support for other serialization formats for >> bcfp messages more usable in browsers (i.e. json or xml). > > WebSocket allows both UTF-8 and binary WebSocket messages. How the JS > client code (in the web application) handles binary data is up to the > developer, but JavaScript is not "byte aware" at all, so probably this > is a show-stopper. > > What I mean is that, prior to starting a work for standarizing BCFP > over WebSocket or over WebRTC Data Channel, it's required to verify > whether the *binary* data carried on top of the transport is > manageable, OR NOT, by a JS application. I insist: JavaScript knows > about unicode symbols, not about bytes. I may miss something, of > course. > > > Regards. > > > > > From pkyzivat@alum.mit.edu Thu Mar 7 09:05:17 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E8221F8A9B for ; Thu, 7 Mar 2013 09:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.209 X-Spam-Level: X-Spam-Status: No, score=-0.209 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 1uCDjnuCuM7i for ; Thu, 7 Mar 2013 09:05:17 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id CF00821F89A6 for ; Thu, 7 Mar 2013 09:05:16 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id 8bgb1l0011ZXKqc59h5GFY; Thu, 07 Mar 2013 17:05:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id 8h5F1l01F3ZTu2S3hh5FFn; Thu, 07 Mar 2013 17:05:16 +0000 Message-ID: <5138C8CB.1060008@alum.mit.edu> Date: Fri, 08 Mar 2013 01:05:15 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <5138B593.9060802@crocodile-rcs.com> <950956C8-EF2A-412A-9941-0975DD73F10A@edvina.net> <5138C54D.601@crocodile-rcs.com> In-Reply-To: <5138C54D.601@crocodile-rcs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362675916; bh=raCdBn8caBceXGExLEvTBivbcCSL2J5QALPscn5Bs14=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dGhIuQCDuvNlbk0UNFHX1coQR8KJAAfpe36dfdcS47/5kG+by7UP2ilb4vOJrz7PJ 7k1sn2yIz7oy5g/2JOzFFIet3eeZTvpjsqaqJEVgCdAIARAnrJVJECqEvwTIdsfLQP yRsw+cUArDJFO01oF5OMWkmvw1alE0CV7HSzIg3RJ8ZqZorgmYUIyO7/9Le3qj5UOo 48l6fcCbaQ/lvLckipXmfUwNxJL0wbyPxhI8MrvYtYgbOnj4sZvT5lmOikRkFAfdNt yMeyJ8I3RzWUJcNHelVAYGYJYXby1wKuOMvGdc4v/IKaMjANxs6of9BFBM433J5K3h 7tKnjgFrlD7+w== Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 17:05:17 -0000 At end On 3/8/13 12:50 AM, Peter Dunkley wrote: > >>>> -- Use of TLS: >>>> >>>> I'm very concerned about downgrading the 4976 MUST on use of TLS >>>> between a client and a relay that it authenticates to. This seems >>>> unacceptable on it's face. You indicate that the client code may >>>> have no control over this--can you elaborate? >>> In a Javascript client running in a browser you can mandate TLS by >>> using a wss:// URL. However: >>> 1) You cannot force mutual TLS or any extended verification - you are >>> stuck with what the browser does >>> 2) Self-signed certificates and certificates where >>> domain-names/addresses do not match are handled badly by browser >>> WebSocket implementations >>> >>> Point 1 means that you will never get the level of security and >>> assurance with TLS for WebSockets that RFC 4976 gives you for >>> ordinary MSRP clients. >>> >>> Point 2: for HTTP you have things like the Firefox add exception >>> dialog (or IE/Chrome warning about the certificate page) to help you >>> with locally defined certificates. There is no such thing for >>> WebSockets and no obvious way of adding it. This means that unless >>> you have specifically configured each computer to accept the >>> certificate the connection establishment will fail. Properly signed >>> certificates used on the Internet will be no problem, but this is a >>> show-stopper if you have a large internal deployment. >>> >>> Because of these points I felt that, while people should be >>> encouraged to be as secure as possible, the use of TLS in this case >>> needs to be a matter of local policy. Leaving the strong >>> requirements of RFC 4976 in place here would result in either a >>> specification that could not be implemented at all, or was simply >>> impractical for many deployments. >>> >>> It should be noted that the TLS requirements are downgraded only for >>> the situation where WebSockets are used. This change does not affect >>> non-WebSocket MSRP relay connections. >> That the current browser implementation sucks in error handling for >> websockets is not a reason to lower the bar in the draft. We've >> successfully raised the bar in regards of security in WebRTC and I >> hope we can keep the bar high here too. >> >> The problem with the wss implementations was shown at SIPit. Hopefully >> it's on the participating browser developer's todo list. If not, it >> should be reported in their bug trackers. It was embarrassing that a >> javascript app developer couldn't get a proper error code for expired >> certs or other TLS connection failures. >> >> /O >> > > Hi Olle, > > This deals with my point 2 (assuming the browser developers do fix the > problems), but it really doesn't help with point 1. Making it possible > to do this level of extended TLS security for WebSockets in a > web-browser is surely well outside of something the IETF can do alone? > After all, it is the W3C that specify the Javascript APIs for managing > WebSocket connections and these would require significant re-work to > support this. > > I'm all for making things as secure as possible, but I can't see this > level of security being achievable from a browser any-time soon. doing MSRP over webrtc data channel would, I think, address these security problems. OTOH it would require waiting for the definition of data channels to be completed. Thanks, Paul From peter.dunkley@crocodile-rcs.com Thu Mar 7 09:13:37 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D374A21F8AEA for ; Thu, 7 Mar 2013 09:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 zcWSEH6HgmjM for ; Thu, 7 Mar 2013 09:13:37 -0800 (PST) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 1069421F8498 for ; Thu, 7 Mar 2013 09:13:34 -0800 (PST) Received: (qmail 25433 invoked by uid 0); 7 Mar 2013 17:13:11 -0000 Received: from unknown (HELO just121.justhost.com) (173.254.28.121) by oproxy13.unifiedlayer.com with SMTP; 7 Mar 2013 17:13:11 -0000 Received: from [90.152.0.102] (port=47128 helo=[192.168.0.156]) by just121.justhost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UDeNT-0005Qj-Aq for dispatch@ietf.org; Thu, 07 Mar 2013 10:13:11 -0700 Message-ID: <5138CAA0.40508@crocodile-rcs.com> Date: Thu, 07 Mar 2013 17:13:04 +0000 From: Peter Dunkley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <5138B593.9060802@crocodile-rcs.com> <950956C8-EF2A-412A-9941-0975DD73F10A@edvina.net> <5138C54D.601@crocodile-rcs.com> <5138C8CB.1060008@alum.mit.edu> In-Reply-To: <5138C8CB.1060008@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {596:just121.justhost.com:crocodi1:crocodile-rcs.com} {sentby:smtp auth 90.152.0.102 authed with peter.dunkley@crocodile-rcs.com} Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 17:13:38 -0000 Also at the end On 07/03/13 17:05, Paul Kyzivat wrote: > At end > > On 3/8/13 12:50 AM, Peter Dunkley wrote: >> >>>>> -- Use of TLS: >>>>> >>>>> I'm very concerned about downgrading the 4976 MUST on use of TLS >>>>> between a client and a relay that it authenticates to. This seems >>>>> unacceptable on it's face. You indicate that the client code may >>>>> have no control over this--can you elaborate? >>>> In a Javascript client running in a browser you can mandate TLS by >>>> using a wss:// URL. However: >>>> 1) You cannot force mutual TLS or any extended verification - you are >>>> stuck with what the browser does >>>> 2) Self-signed certificates and certificates where >>>> domain-names/addresses do not match are handled badly by browser >>>> WebSocket implementations >>>> >>>> Point 1 means that you will never get the level of security and >>>> assurance with TLS for WebSockets that RFC 4976 gives you for >>>> ordinary MSRP clients. >>>> >>>> Point 2: for HTTP you have things like the Firefox add exception >>>> dialog (or IE/Chrome warning about the certificate page) to help you >>>> with locally defined certificates. There is no such thing for >>>> WebSockets and no obvious way of adding it. This means that unless >>>> you have specifically configured each computer to accept the >>>> certificate the connection establishment will fail. Properly signed >>>> certificates used on the Internet will be no problem, but this is a >>>> show-stopper if you have a large internal deployment. >>>> >>>> Because of these points I felt that, while people should be >>>> encouraged to be as secure as possible, the use of TLS in this case >>>> needs to be a matter of local policy. Leaving the strong >>>> requirements of RFC 4976 in place here would result in either a >>>> specification that could not be implemented at all, or was simply >>>> impractical for many deployments. >>>> >>>> It should be noted that the TLS requirements are downgraded only for >>>> the situation where WebSockets are used. This change does not affect >>>> non-WebSocket MSRP relay connections. >>> That the current browser implementation sucks in error handling for >>> websockets is not a reason to lower the bar in the draft. We've >>> successfully raised the bar in regards of security in WebRTC and I >>> hope we can keep the bar high here too. >>> >>> The problem with the wss implementations was shown at SIPit. Hopefully >>> it's on the participating browser developer's todo list. If not, it >>> should be reported in their bug trackers. It was embarrassing that a >>> javascript app developer couldn't get a proper error code for expired >>> certs or other TLS connection failures. >>> >>> /O >>> >> >> Hi Olle, >> >> This deals with my point 2 (assuming the browser developers do fix the >> problems), but it really doesn't help with point 1. Making it possible >> to do this level of extended TLS security for WebSockets in a >> web-browser is surely well outside of something the IETF can do alone? >> After all, it is the W3C that specify the Javascript APIs for managing >> WebSocket connections and these would require significant re-work to >> support this. >> >> I'm all for making things as secure as possible, but I can't see this >> level of security being achievable from a browser any-time soon. > > doing MSRP over webrtc data channel would, I think, address these > security problems. > > OTOH it would require waiting for the definition of data channels to > be completed. > As has been discussed in the "Remapping existing protocols..." thread, WebRTC data channel is not a great solution for browser to server communications. There are many reasons to use an MSRP relay: - Regulatory monitoring/logging - Local policy (within organisation) monitoring/logging - Interoperation with existing MSRP clients MSRP over WebRTC data channel would be fine if the use case was secure messaging communications between browsers without any requirement for logging. But I think WebSocket is the way to go for use cases that need a server involved. Regards, Peter From oej@edvina.net Thu Mar 7 09:26:38 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9327121F8AD1 for ; Thu, 7 Mar 2013 09:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 2MQWHEuRZILR for ; Thu, 7 Mar 2013 09:26:38 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 7147921F8996 for ; Thu, 7 Mar 2013 09:26:36 -0800 (PST) Received: from [192.168.40.5] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E368D93DE3C; Thu, 7 Mar 2013 17:26:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <5138C8CB.1060008@alum.mit.edu> Date: Thu, 7 Mar 2013 18:26:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <5138B593.9060802@crocodile-rcs.com> <950956C8-EF2A-412A-9941-0975DD73F10A@edvina.net> <5138C54D.601@crocodile-rcs.com> <5138C8CB.1060008@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1499) Cc: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 17:26:38 -0000 7 mar 2013 kl. 18:05 skrev Paul Kyzivat : > At end >=20 > On 3/8/13 12:50 AM, Peter Dunkley wrote: >>=20 >>>>> -- Use of TLS: >>>>>=20 >>>>> I'm very concerned about downgrading the 4976 MUST on use of TLS >>>>> between a client and a relay that it authenticates to. This seems >>>>> unacceptable on it's face. You indicate that the client code may >>>>> have no control over this--can you elaborate? >>>> In a Javascript client running in a browser you can mandate TLS by >>>> using a wss:// URL. However: >>>> 1) You cannot force mutual TLS or any extended verification - you = are >>>> stuck with what the browser does >>>> 2) Self-signed certificates and certificates where >>>> domain-names/addresses do not match are handled badly by browser >>>> WebSocket implementations >>>>=20 >>>> Point 1 means that you will never get the level of security and >>>> assurance with TLS for WebSockets that RFC 4976 gives you for >>>> ordinary MSRP clients. >>>>=20 >>>> Point 2: for HTTP you have things like the Firefox add exception >>>> dialog (or IE/Chrome warning about the certificate page) to help = you >>>> with locally defined certificates. There is no such thing for >>>> WebSockets and no obvious way of adding it. This means that unless >>>> you have specifically configured each computer to accept the >>>> certificate the connection establishment will fail. Properly = signed >>>> certificates used on the Internet will be no problem, but this is a >>>> show-stopper if you have a large internal deployment. >>>>=20 >>>> Because of these points I felt that, while people should be >>>> encouraged to be as secure as possible, the use of TLS in this case >>>> needs to be a matter of local policy. Leaving the strong >>>> requirements of RFC 4976 in place here would result in either a >>>> specification that could not be implemented at all, or was simply >>>> impractical for many deployments. >>>>=20 >>>> It should be noted that the TLS requirements are downgraded only = for >>>> the situation where WebSockets are used. This change does not = affect >>>> non-WebSocket MSRP relay connections. >>> That the current browser implementation sucks in error handling for >>> websockets is not a reason to lower the bar in the draft. We've >>> successfully raised the bar in regards of security in WebRTC and I >>> hope we can keep the bar high here too. >>>=20 >>> The problem with the wss implementations was shown at SIPit. = Hopefully >>> it's on the participating browser developer's todo list. If not, it >>> should be reported in their bug trackers. It was embarrassing that a >>> javascript app developer couldn't get a proper error code for = expired >>> certs or other TLS connection failures. >>>=20 >>> /O >>>=20 >>=20 >> Hi Olle, >>=20 >> This deals with my point 2 (assuming the browser developers do fix = the >> problems), but it really doesn't help with point 1. Making it = possible >> to do this level of extended TLS security for WebSockets in a >> web-browser is surely well outside of something the IETF can do = alone? >> After all, it is the W3C that specify the Javascript APIs for = managing >> WebSocket connections and these would require significant re-work to >> support this. >>=20 >> I'm all for making things as secure as possible, but I can't see this >> level of security being achievable from a browser any-time soon. >=20 > doing MSRP over webrtc data channel would, I think, address these = security problems. >=20 > OTOH it would require waiting for the definition of data channels to = be completed. I think that's a different usage model. If you can do peer2peer chat, = that works. If the other party is on a SIP device somewhere within the SIP network, using = browser technology would not work. /O= From partha@parthasarathi.co.in Thu Mar 7 09:40:19 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B074721F8A4E for ; Thu, 7 Mar 2013 09:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6] 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 tDeiaAATxTam for ; Thu, 7 Mar 2013 09:40:18 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id C057C21F8A51 for ; Thu, 7 Mar 2013 09:40:18 -0800 (PST) Received: from userPC (unknown [122.179.37.91]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id C71201EBF7D1; Thu, 7 Mar 2013 17:40:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1362678018; bh=Dx25+GKC63yPMGXARrxPpgsAjkr8dtBi7B7xl1BrZyY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QzFGxDudKQUDaKaD0sJRLfiuc2uNZlR6fxwFkJAqUw0KYgF3eDK2blpK2QNH5GfqO 8RbrOwdgpZtLMNDWFx4kvX3QnFCseQxhmc2THgG/ED3BKrAoQM2yoEajDwtqoFKqZ6 BikqNIlB0m90YMbG4XOQz+ONIZEc6cxNHEImXi8Q= From: "Parthasarathi R" To: "'Paul Kyzivat'" , References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> <5138C7E8.1090002@alum.mit.edu> In-Reply-To: <5138C7E8.1090002@alum.mit.edu> Date: Thu, 7 Mar 2013 23:10:08 +0530 Message-ID: <005801ce1b5a$d358ecb0$7a0ac610$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4bVXPXdzGBs7DfQPWyThoUHRDVSgAA0bNg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0209.5138D102.00AD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 17:40:19 -0000 Paul, > OTOH (1) may be easier to implement when the other end is a server > rather than a browser. Hope you assume that server is the combination of signaling & media = entity. (1) is not good in case server is designed in a decomposed way = wherein signaling & media are handled by different physical entity in = the server.=20 Thanks Partha > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, March 07, 2013 10:31 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] FW: New Version Notification for = draft-pascual- > dispatch-bfcp-websocket-00.txt >=20 > I=C3=B1aki, >=20 > Yes, IIUC the existing BFCP can't be used from a browser - neither the > TCP nor the UDP form. And that won't be fixed by webrtc. >=20 > So what to do about that? It appears there are three possibilities: >=20 > 1) A new mapping of BFCP over websockets >=20 > 2) A new mapping of BFCP over webrtc data channel >=20 > 3) build a BFCP "proxy" in the web server, converting to proprietary > signaling between the web server and the browser. >=20 > Hopefully we can discard (3) as unreasonable. >=20 > It sounds like (2) will be more secure unless some improvements are > made > to websockets. >=20 > And (2) will work when doing BFCP pt-pt between two browsers, where = (1) > won't without some sort of proxy in the middle. >=20 > OTOH (1) may be easier to implement when the other end is a server > rather than a browser. Hope you assume that server is the combination of signaling & = media entity. (1) is not good in case server is designed in a decomposed = way wherein signaling & media are handled in different physical entity. = >=20 > Thanks, > Paul >=20 >=20 > On 3/7/13 1:00 AM, I=C3=B1aki Baz Castillo wrote: > > 2013/3/4 Sergio Garcia Murillo : > >> So, as in our case, we will be implementing bcfp over websockets in > any case > >> to support this html interface, it would be great to be able to > reuse the > >> same implementation for webrtc clients (i.e exchanging the set up > >> information in the sdp), and avoid the costs of implementing > datachannels at > >> all. > > > > I don't know BCFP, but by looking at SDP examples in RFC 4583 I see > this: > > > > --------------- > > m=3Dapplication 50000 TCP/TLS/BFCP * > > a=3Dsetup:passive > > a=3Dconnection:new > > a=3Dfingerprint:SHA-1 \ > > 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB > > a=3Dfloorctrl:s-only > > a=3Dconfid:4321 > > a=3Duserid:1234 > > a=3Dfloorid:1 m-stream:10 > > a=3Dfloorid:2 m-stream:11 > > m=3Daudio 50002 RTP/AVP 0 > > a=3Dlabel:10 > > m=3Dvideo 50004 RTP/AVP 31 > > a=3Dlabel:11 > > --------------- > > > > Well, I strongly hope nobody plans to pass such an SDP to a WebRTC > > RTCPeerConnection constructor since it will die. This is, I hope > > running BCFP does not require sending an INVITE with SDP containing > > both audio/video data and BCFP data, because that will never work in > > WebRTC land, and playing with JavaScript for parsing, splitting and > > merging SDP fragments is not funny at all. > > > > > > > >> Also, as a side discussion, regardless of the transport chosen, I > don't see > >> managing binary messages in the browser is something natural, if > possible, > >> it would be a good idea to add support for other serialization > formats for > >> bcfp messages more usable in browsers (i.e. json or xml). > > > > WebSocket allows both UTF-8 and binary WebSocket messages. How the = JS > > client code (in the web application) handles binary data is up to = the > > developer, but JavaScript is not "byte aware" at all, so probably > this > > is a show-stopper. > > > > What I mean is that, prior to starting a work for standarizing BCFP > > over WebSocket or over WebRTC Data Channel, it's required to verify > > whether the *binary* data carried on top of the transport is > > manageable, OR NOT, by a JS application. I insist: JavaScript knows > > about unicode symbols, not about bytes. I may miss something, of > > course. > > > > > > Regards. > > > > > > > > > > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Thu Mar 7 09:43:46 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C5521F8AB8 for ; Thu, 7 Mar 2013 09:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.151 X-Spam-Level: X-Spam-Status: No, score=-103.151 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 gckfNxP1-GK2 for ; Thu, 7 Mar 2013 09:43:45 -0800 (PST) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 12C0F21F8A51 for ; Thu, 7 Mar 2013 09:43:41 -0800 (PST) Received: by mail-qe0-f49.google.com with SMTP id 1so438555qec.8 for ; Thu, 07 Mar 2013 09:43:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=aZKAEO8ZQ+tEYtUdfssxPfSR1envYbEytM/KWf5q9gw=; b=CFtGEbcTZhb1drz0PC3u1l5Zyo+d9oZm9dUOXfGn2ajK+tNVkbivLULULPlTxhb52q cKmrk5w/J8xM92OOKTx46WfbfAEZt/Gm+iXuAZ9e6xfT0XEUk9wyezyeSptOTpXsVpBt yZTs/dELznkFPJcjCYvun8i96kWdYw5jlQM6xpqMF/0jHaa9BiEcRLR0e4wwlgRKFgSa X4naiaPQWc2SxsHcoaLb1WY8WtyFLkRJGDEfslMX9QPxUAoGL/QU+33ULfF29ZJnO+Jw yWcXrmy2/pcsm6aMo+pYz/dKwkZ9OnhL8Oi8h7L8Qmx8GcPCVOKaf1LJ9CRFt+G7lB/R Sx6A== MIME-Version: 1.0 X-Received: by 10.229.137.75 with SMTP id v11mr11834290qct.26.1362678221544; Thu, 07 Mar 2013 09:43:41 -0800 (PST) Received: by 10.49.24.130 with HTTP; Thu, 7 Mar 2013 09:43:41 -0800 (PST) In-Reply-To: <5138C7E8.1090002@alum.mit.edu> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> <5138C7E8.1090002@alum.mit.edu> Date: Thu, 7 Mar 2013 11:43:41 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 17:43:46 -0000 Personally, I think one is a better approach. There may be applications that want to use BFCP that don't want to the WebRTC data channel. While we think CLUE might use the WebRTC data channel that is not yet a given. Thus, I am far more comfortable with the 1) moving forward. Mary. On Thu, Mar 7, 2013 at 11:01 AM, Paul Kyzivat wrote= : > I=F1aki, > > Yes, IIUC the existing BFCP can't be used from a browser - neither the TC= P > nor the UDP form. And that won't be fixed by webrtc. > > So what to do about that? It appears there are three possibilities: > > 1) A new mapping of BFCP over websockets > > 2) A new mapping of BFCP over webrtc data channel > > 3) build a BFCP "proxy" in the web server, converting to proprietary > signaling between the web server and the browser. > > Hopefully we can discard (3) as unreasonable. > > It sounds like (2) will be more secure unless some improvements are made = to > websockets. > > And (2) will work when doing BFCP pt-pt between two browsers, where (1) > won't without some sort of proxy in the middle. > > OTOH (1) may be easier to implement when the other end is a server rather > than a browser. > > Thanks, > Paul > > > > On 3/7/13 1:00 AM, I=F1aki Baz Castillo wrote: >> >> 2013/3/4 Sergio Garcia Murillo : >>> >>> So, as in our case, we will be implementing bcfp over websockets in any >>> case >>> to support this html interface, it would be great to be able to reuse t= he >>> same implementation for webrtc clients (i.e exchanging the set up >>> information in the sdp), and avoid the costs of implementing datachanne= ls >>> at >>> all. >> >> >> I don't know BCFP, but by looking at SDP examples in RFC 4583 I see this= : >> >> --------------- >> m=3Dapplication 50000 TCP/TLS/BFCP * >> a=3Dsetup:passive >> a=3Dconnection:new >> a=3Dfingerprint:SHA-1 \ >> 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB >> a=3Dfloorctrl:s-only >> a=3Dconfid:4321 >> a=3Duserid:1234 >> a=3Dfloorid:1 m-stream:10 >> a=3Dfloorid:2 m-stream:11 >> m=3Daudio 50002 RTP/AVP 0 >> a=3Dlabel:10 >> m=3Dvideo 50004 RTP/AVP 31 >> a=3Dlabel:11 >> --------------- >> >> Well, I strongly hope nobody plans to pass such an SDP to a WebRTC >> RTCPeerConnection constructor since it will die. This is, I hope >> running BCFP does not require sending an INVITE with SDP containing >> both audio/video data and BCFP data, because that will never work in >> WebRTC land, and playing with JavaScript for parsing, splitting and >> merging SDP fragments is not funny at all. >> >> >> >>> Also, as a side discussion, regardless of the transport chosen, I don't >>> see >>> managing binary messages in the browser is something natural, if >>> possible, >>> it would be a good idea to add support for other serialization formats >>> for >>> bcfp messages more usable in browsers (i.e. json or xml). >> >> >> WebSocket allows both UTF-8 and binary WebSocket messages. How the JS >> client code (in the web application) handles binary data is up to the >> developer, but JavaScript is not "byte aware" at all, so probably this >> is a show-stopper. >> >> What I mean is that, prior to starting a work for standarizing BCFP >> over WebSocket or over WebRTC Data Channel, it's required to verify >> whether the *binary* data carried on top of the transport is >> manageable, OR NOT, by a JS application. I insist: JavaScript knows >> about unicode symbols, not about bytes. I may miss something, of >> course. >> >> >> Regards. >> >> >> >> >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Thu Mar 7 10:05:17 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07C421F882F for ; Thu, 7 Mar 2013 10:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.224 X-Spam-Level: X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 2ZRZ+H+acPIe for ; Thu, 7 Mar 2013 10:05:17 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 3A58221F8826 for ; Thu, 7 Mar 2013 10:05:17 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta04.westchester.pa.mail.comcast.net with comcast id 8cog1l0041vXlb854i5G6h; Thu, 07 Mar 2013 18:05:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id 8i5G1l00D3ZTu2S3di5GQo; Thu, 07 Mar 2013 18:05:16 +0000 Message-ID: <5138D6DB.3060603@alum.mit.edu> Date: Fri, 08 Mar 2013 02:05:15 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Olle E. Johansson" References: <20121217161521.30393.14625.idtracker@ietfa.amsl.com> <5138B593.9060802@crocodile-rcs.com> <950956C8-EF2A-412A-9941-0975DD73F10A@edvina.net> <5138C54D.601@crocodile-rcs.com> <5138C8CB.1060008@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362679516; bh=fhVG6Kwoi9F+yTX0iFX5eseNUBV8T6YD5ONW9MvlwVc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ea1GerOwxmaZ0SDY0qWzigOmRm+txokhHkWCukuo6vOvFvZK6bW6lXlqItcar1DkT vLJ25/GUDdEC2P/RG2OdqdtF6aHSYg1ZL2agiKPFt6+FuEZh3SX0s5ppM5TZoJEWjt 9HjWSyDB6XsKkHhYesb/KFAbW3d8uKs6oCig5ZOI+dZvyilb8t7rOeSxeOA3/+vvi0 Wu5tFf0E20CHJR3hSAbZ13XQ/iyRHJV8CFGloD88A0Y8EHMbfOMU3xEsYwchxRKAo4 AC7lu8HKWs6K1Nl+DZGzHBX5PMdJHG6HnWhadlforH281fMdtN2/6abyGPV4TiCPq/ ysFEeF69UF7UQ== Cc: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-pd-dispatch-msrp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 18:05:18 -0000 On 3/8/13 1:26 AM, Olle E. Johansson wrote: snip >>> I'm all for making things as secure as possible, but I can't see this >>> level of security being achievable from a browser any-time soon. >> >> doing MSRP over webrtc data channel would, I think, address these security problems. >> >> OTOH it would require waiting for the definition of data channels to be completed. > > I think that's a different usage model. If you can do peer2peer chat, that works. If the > other party is on a SIP device somewhere within the SIP network, using browser > technology would not work. The data channel stuff is being defined first for rtcweb. But that doesn't mean it is exclusively *browser technology*, or *web technology*. Websockets are *web technology*. CLUE is going to use the data channel technology for its own clue signaling channel. We are doing this for two reasons: - It will provide a solution that works through nats (with ICE) and provides a reliable transport. And rtcweb is doing the work of getting it defined, so we don't have to do it. - We want to make it possible for webrtc clients to be clue endpoints. So clue components, most of which will not be browsers, will be implementing this mechanism. That includes clue conference servers (MCUs). Those same servers will probably also use BFCP, so it would be convenient if we had BFCP over data channel so browsers could participate and the servers could use the same stack for both protocols. CLUE isn't currently talking about IM, but that could happen in the future. If so, MSRP over data channel might also be convenient. Thanks, Paul From pkyzivat@alum.mit.edu Thu Mar 7 10:12:05 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2420A21F8A3E for ; Thu, 7 Mar 2013 10:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.369 X-Spam-Level: X-Spam-Status: No, score=0.369 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] 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 8ytCnPwM6Yer for ; Thu, 7 Mar 2013 10:12:04 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 0224821F8A05 for ; Thu, 7 Mar 2013 10:12:03 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id 8bSx1l0030xGWP853iC3Ft; Thu, 07 Mar 2013 18:12:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id 8iC31l0093ZTu2S3YiC3iy; Thu, 07 Mar 2013 18:12:03 +0000 Message-ID: <5138D872.2050705@alum.mit.edu> Date: Fri, 08 Mar 2013 02:12:02 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mary Barnes References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> <5138C7E8.1090002@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362679923; bh=gZnDCsQvRjNqNYYMh9UD3EOiRECaxvwURrShQcIUfq8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IcuFJl5NaHWTcEplI9j2KxxUCxQMOPrP0/raqkZXnd769uQCm9E4AvqZckkd5RHqr /2uDwmXB7JKZM3ZeRqnpH2pVJldL/5i0UhVyA/KDGV7fb0QPtTcBkKBjfiqLPbcBLV IXSvq6VrjAaex1k95PEC14n7b2p+4qxRuUlWQUYASvz1YZK+j2bd9CBEMnzN1QDaPn dm3jD71SEVYiy1DW/I7JVQrZEYDnbXdlDMfJoyEQFqJ/glcQief/u+q90lVEZzxwig omFOCMabDs5kx5BmSBzaoFrxbEPEa+efpj9sI1h69yikDJmzowcmgYJr1hOcebbu1n kotxkorrs1gUg== Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 18:12:05 -0000 For BFCP I don't have a strong preference. I notice in the conversation about mrsp over websocket that there is some concern over the level of security possible with websockets. That should at least be considered, though maybe BFCP isn't at the top of anyone's list of security concerns. Thanks, Paul On 3/8/13 1:43 AM, Mary Barnes wrote: > > > Personally, I think one is a better approach. There may be > applications that want to use BFCP that don't want to the WebRTC data > channel. While we think CLUE might use the WebRTC data channel that > is not yet a given. Thus, I am far more comfortable with the 1) > moving forward. > > Mary. > > On Thu, Mar 7, 2013 at 11:01 AM, Paul Kyzivat wrote: >> Iñaki, >> >> Yes, IIUC the existing BFCP can't be used from a browser - neither the TCP >> nor the UDP form. And that won't be fixed by webrtc. >> >> So what to do about that? It appears there are three possibilities: >> >> 1) A new mapping of BFCP over websockets >> >> 2) A new mapping of BFCP over webrtc data channel >> >> 3) build a BFCP "proxy" in the web server, converting to proprietary >> signaling between the web server and the browser. >> >> Hopefully we can discard (3) as unreasonable. >> >> It sounds like (2) will be more secure unless some improvements are made to >> websockets. >> >> And (2) will work when doing BFCP pt-pt between two browsers, where (1) >> won't without some sort of proxy in the middle. >> >> OTOH (1) may be easier to implement when the other end is a server rather >> than a browser. >> >> Thanks, >> Paul >> >> >> >> On 3/7/13 1:00 AM, Iñaki Baz Castillo wrote: >>> >>> 2013/3/4 Sergio Garcia Murillo : >>>> >>>> So, as in our case, we will be implementing bcfp over websockets in any >>>> case >>>> to support this html interface, it would be great to be able to reuse the >>>> same implementation for webrtc clients (i.e exchanging the set up >>>> information in the sdp), and avoid the costs of implementing datachannels >>>> at >>>> all. >>> >>> >>> I don't know BCFP, but by looking at SDP examples in RFC 4583 I see this: >>> >>> --------------- >>> m=application 50000 TCP/TLS/BFCP * >>> a=setup:passive >>> a=connection:new >>> a=fingerprint:SHA-1 \ >>> 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB >>> a=floorctrl:s-only >>> a=confid:4321 >>> a=userid:1234 >>> a=floorid:1 m-stream:10 >>> a=floorid:2 m-stream:11 >>> m=audio 50002 RTP/AVP 0 >>> a=label:10 >>> m=video 50004 RTP/AVP 31 >>> a=label:11 >>> --------------- >>> >>> Well, I strongly hope nobody plans to pass such an SDP to a WebRTC >>> RTCPeerConnection constructor since it will die. This is, I hope >>> running BCFP does not require sending an INVITE with SDP containing >>> both audio/video data and BCFP data, because that will never work in >>> WebRTC land, and playing with JavaScript for parsing, splitting and >>> merging SDP fragments is not funny at all. >>> >>> >>> >>>> Also, as a side discussion, regardless of the transport chosen, I don't >>>> see >>>> managing binary messages in the browser is something natural, if >>>> possible, >>>> it would be a good idea to add support for other serialization formats >>>> for >>>> bcfp messages more usable in browsers (i.e. json or xml). >>> >>> >>> WebSocket allows both UTF-8 and binary WebSocket messages. How the JS >>> client code (in the web application) handles binary data is up to the >>> developer, but JavaScript is not "byte aware" at all, so probably this >>> is a show-stopper. >>> >>> What I mean is that, prior to starting a work for standarizing BCFP >>> over WebSocket or over WebRTC Data Channel, it's required to verify >>> whether the *binary* data carried on top of the transport is >>> manageable, OR NOT, by a JS application. I insist: JavaScript knows >>> about unicode symbols, not about bytes. I may miss something, of >>> course. >>> >>> >>> Regards. >>> >>> >>> >>> >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From ibc@aliax.net Thu Mar 7 13:27:51 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F35421F8ABC for ; Thu, 7 Mar 2013 13:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 NGdcY0llmvvC for ; Thu, 7 Mar 2013 13:27:51 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2CC21F897F for ; Thu, 7 Mar 2013 13:27:50 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id a22so325437qcs.12 for ; Thu, 07 Mar 2013 13:27:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=RuSbPoALK7LUFNwJ29GJOWk9BWgaVEIPgD+YfKf6nUU=; b=Xsd0Ephx+1YX8EmgxAguhufT8ppgy4/2hBjUCpT6W5Ei35L23HOAtsWvWbITiPnb+y 4O0RjqvaiCLyD/dkQQ+yidaq9/e1kXnTOn1w7dm6hk5takpI0RLpBbYQRmbj0M7cb9cp Dm5DyGzK45O8EyhNUXaJTLxohukmETR+cWWrEX+7GY2g4AZAV1tP8CNFz4NXMjMsNQfX 71GtADK0vAdAR5M0TzFINRznAzpASY8iqza8MxVpTtc5RYRgtem6hf4OjqUUE55diRsJ qEkeM63RBe6pj/0iBezrA2RgW2E5OEC3g3Oh14vXBiUtjodr7PaTtUkPZAu0vb4kCaip X0FA== X-Received: by 10.224.191.68 with SMTP id dl4mr390688qab.85.1362691670456; Thu, 07 Mar 2013 13:27:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.12.233 with HTTP; Thu, 7 Mar 2013 13:27:30 -0800 (PST) In-Reply-To: <5138D872.2050705@alum.mit.edu> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> <5138C7E8.1090002@alum.mit.edu> <5138D872.2050705@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 7 Mar 2013 22:27:30 +0100 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlHLDvVhILgvoNh9pbtmwTRTK0OhT9fR77bOr1Pap3oflkAME8J94GHaApsp//3OyETts8R Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 21:27:51 -0000 2013/3/7 Paul Kyzivat : > I notice in the conversation about mrsp over websocket that there is some > concern over the level of security possible with websockets. Hi Paul, which are those security concerns about WebSocket? More then 500 millons of persons chat via HTTPS (Facebook). WebSocket provides similar security (as the authorization can also be done via Cookies and the traffic can be encrypted via SSL/TLS when ussing WSS). Maybe the concerns you mean are just when implementing MSRP over WebSocket? --=20 I=C3=B1aki Baz Castillo From sergio.garcia.murillo@gmail.com Thu Mar 7 13:34:00 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6695C21F8450 for ; Thu, 7 Mar 2013 13:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] 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 uTY+gLXTdoqT for ; Thu, 7 Mar 2013 13:33:56 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7D26021F852B for ; Thu, 7 Mar 2013 13:33:56 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so3947282wie.0 for ; Thu, 07 Mar 2013 13:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kw1pwxLST5YNY2IrUnAMDOUgrXLMTLCQqdjo1hR0K4k=; b=fQs7Mse/2H/6rs+++7EkbFicKRi5OefAQxgAm8Aaeao5AaMcxeFcVhrKrDfqFoufL4 b8d/Jt4h+jQp4+5CBuxdG1NxAghCS1vXn4if8NykHDPD5L+M/fOtJfVlDoRa6Tp6Cbok 0MsJ7CR0/gFf2hztt4TtX2H8IOSEz4g6EQtAJdGFjV0wet5taJWDTK9+PCXqDmLfyyft nzp6mLdpk9G1s3me0ZH7LRDypadgFzpePDPyNMZQ6R7fsDbpxXFvf84ter2v2EAitx8x 2PmGNcNjAbZLK0x0VaLnJJc6EEzuH5aUp14e04cTG6h0tJkaOxqovG5h5/+ujtbFSzvD 6jxQ== X-Received: by 10.180.93.234 with SMTP id cx10mr36503628wib.34.1362692035111; Thu, 07 Mar 2013 13:33:55 -0800 (PST) Received: from [192.168.1.2] (122.pool80-103-141.dynamic.orange.es. [80.103.141.122]) by mx.google.com with ESMTPS id k5sm5641219wiy.5.2013.03.07.13.33.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Mar 2013 13:33:54 -0800 (PST) Message-ID: <513907CC.8030807@gmail.com> Date: Thu, 07 Mar 2013 22:34:04 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> <5138C7E8.1090002@alum.mit.edu> <005801ce1b5a$d358ecb0$7a0ac610$@co.in> In-Reply-To: <005801ce1b5a$d358ecb0$7a0ac610$@co.in> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 21:34:02 -0000 El 07/03/2013 18:40, Parthasarathi R escribió: > Paul, > >> OTOH (1) may be easier to implement when the other end is a server >> rather than a browser. > Hope you assume that server is the combination of signaling & media entity. (1) is not good in case server is designed in a decomposed way wherein signaling & media are handled by different physical entity in the server. I have implemented the MCU with independent signaling and media components and that is not a problem for me. I will implement websockets support in the media component without much effort. Best regards Sergio From jon.peterson@neustar.biz Thu Mar 7 15:30:11 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEF221F86BB for ; Thu, 7 Mar 2013 15:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 7rhup6Sei3N3 for ; Thu, 7 Mar 2013 15:30:10 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B6EB921F86BA for ; Thu, 7 Mar 2013 15:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1362699197; x=1678057701; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=RF7Eg2JydVNtdQENbcI22 cbZdS64ODTGJtWdotOVC3g=; b=CemDZti+Ur/HgHzIcxDSacNc9pyCekOxdsmVE 8jTxeS24e1S7P+oeK2VRxHtRX9FrqJwSfZp5u7WBBdqPvnHsQ== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.20655623; Thu, 07 Mar 2013 18:33:16 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 7 Mar 2013 18:30:04 -0500 From: "Peterson, Jon" To: "dispatch@ietf.org" Date: Thu, 7 Mar 2013 18:27:14 -0500 Thread-Topic: terq charter revision Thread-Index: AQHOG4uwJd1j/+51NEWjvHcnnYJWfg== Message-ID: <55A5A9A87506CB4BA580BF9D531957DA921A0424@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: u9Xhlewjv+McyhJDr0Ra3w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] terq charter revision X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 23:30:11 -0000 Based on the comments previously received, this is a slight revision to the= TeRQ charter. The fundamentals here though are pretty much unchanged: the = plan is to do the framework and information model document and one binding = document, rechartering if there is interest in doing any further binding do= cuments. Jon Peterson NeuStar, Inc. --- Title: Telephony-Related Queries Acronym: terq Area: Real-time Applications and Infrastructure Area Director: TBD Chair(s): TBD Mailing address: TBD (currently dispatch@ietf.org) Description of Working Group Several IETF efforts have studied the handling of telephone numbers on the = Internet. For example, the ENUM working group specified a DNS-based approac= h to transforming telephone numbers into URIs; the DRINKS working group pro= duced a provisioning system suitable for populating Internet directories of= telephone numbers. The overall goal of this work has been to migrate the r= outing and directory functions of the telephone network onto the Internet, = in order to simplify the implementation of Internet telephony and reduce th= e Internet's reliance on the infrastructure of the public switched telephon= e network. Ultimately, the requirements for this project diverged significa= ntly from the original architecture and applicability of ENUM. Moreover, in= the twelve years since ENUM was first chartered, Internet telephony has ch= anged a great deal. As one example, today web-based applications are becomi= ng more significant to Internet telephony, as are intelligent mobile device= s. In these environments, there exists a capacity for richer queries and re= sponses, as well as more sophisticated application logic to process request= s, but also tougher security requirements. As such, this working group reco= nsiders the migration of routing and directory functions from the telephone= network to the Internet by generalizing the base semantics of queries and = responses in an abstract framework, and then defining possible transports a= nd encodings for these messages. The components of the chartered work include: 1. A framework and information model for the construction queries and respo= nses. The information model will provide an abstract description of the sem= antics of the various elements and attributes that make up TeRQ messages. T= he framework will further establish the semantics of TeRQ transactions, des= cribe how responses are matched with queries, and give an overview of the o= peration of the protocol. It will furthermore describe the overall security= model of TeRQ, including confidentiality and access control measures neces= sary to preserve privacy. 2. A process for specifying bindings for the information model, which compr= ise transports and encodings. Transports specify the underlying protocols t= hat will encapsulate TeRQ queries and responses. This working group is not = chartered to define new underlying protocols, but will specify how the tran= saction model of TeRQ maps onto these underlying protocols. Potential under= lying protocols include HTTP and DIAMETER. The encoding determines how TeRQ= elements and attributes will be rendered in the object format carried by t= he transport; potential object formats would include JSON and XML and well = as lower-layer encodings. Binding specifications must detail their implemen= tation of the security and privacy requirements defined in the framework. 3. A set of one or more bindings compliant with the process described in (2= ), which provide a concrete instantiation of the protocol. This group will = be initially chartered to create a single binding, though other may be a po= tential subject for ongoing work after a rechart. These bindings may accomp= any profiles that detail particular sets of attributes or elements relevant= to a given deployment. The TeRQ working group will coordinate with ongoing work in the DRINKS spac= e in order to make sure that the TeRQ information model conforms with the n= eeds of provisioning systems. Whenever possible, TeRQ will reuse existing I= ETF work. The syntax and semantics of telephone numbers, for example, have = been the subject of a great deal of previous IETF work (notably RFC 3966), = and the TeRQ working group will rely on this and related prior work.=20 Goals and Deliverables: Aug 2013 Submit Framework for Telephony Related Queries as Proposed Standar= d Nov 2013 Submit one TeRQ Binding as Proposed Standard Feb 2013 Recharter if additional bindings are required= From stpeter@stpeter.im Fri Mar 8 11:28:07 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C0221F886D for ; Fri, 8 Mar 2013 11:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 TzIxroZ2jMi7 for ; Fri, 8 Mar 2013 11:28:06 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6559021F862A for ; Fri, 8 Mar 2013 11:28:06 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F14844004E; Fri, 8 Mar 2013 12:36:25 -0700 (MST) Message-ID: <513A3BC0.9050809@stpeter.im> Date: Fri, 08 Mar 2013 12:28:00 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mary Barnes References: <5137AC9E.5080608@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Richard Barnes , DISPATCH , "rai-ads@tools.ietf.org" Subject: Re: [dispatch] IETF-86 DISPATCH Topics X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 19:28:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/7/13 7:22 AM, Mary Barnes wrote: > Peter, > > Thank you very much! I have uploaded to the proceedings: > https://datatracker.ietf.org/meeting/86/materials.html > > Just let us know if you do make any changes so we can make sure > and have the right version available. I have corrected a few points in the slides and have uploaded them in place at https://stpeter.im/files/ietf86-dispatch-sip-xmpp.pdf Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJROjvAAAoJEOoGpJErxa2pOOIP/1Pvtd4w69iTOYUklCNZXYFT 1GP9P+I5ghI1wSScPMS6nAdF3sP1zQq54VHq4d0pGlf3PGs7j3bjRhnufsdTcrRz xHsxAeljyp2rhnSEuSEtbp/zIY78AukAMW/0VPKbERb2dbRcEZkFJ6aZUZb46Rdp e+UYjgruGMsWuRf/Q1WX3P/wgce7CWN4JDnHoKYuee/LKxe3eMS85+Ku7BuUveBE GhIZE+UpLSy8C4t3RhCq9pj56ZiyME9tefdckSIBGk6M3LAVxj+DFb8q+mfCnQTZ a83qeQ35lBpMI4ZqUd48/yBSgHMXjaZrQrNVTzst+IlODsCtX3xNoXdVw50ZoC+j jKk1ESiWzPm2spTEmyC0EBOYMmrRmcAi2sPwFLRM7GYNiioVPqapaSXxzhzQAecu mNTRLVyAGXHCk5CQ88tymxdJ7A4GYLTB/4jHeJ3qOzSihSYw9mRcIzivQGDH0l8u K/UIddh3bCDyjUDNghrdlW5zQgIeNpvcw0HKgnvb7V0RFfQ4694mbrasXIo6dKWc s0ReJwQvhl9KeyERYeeBgrnEBt3b7qdmGCjEzbmqPLkUPxlg4m9HdaWbRjcRrvx9 YkXxNCCerF/G1RFvFry7G7AcakO+g+0x7+UBIjLx+uZygXePdPVubVAODuDNzahI /Rk/v67qKUh4IA7CEVAW =N0mR -----END PGP SIGNATURE----- From fluffy@cisco.com Sat Mar 9 06:35:05 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4845021F85E0 for ; Sat, 9 Mar 2013 06:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 CF4anlRZSRTy for ; Sat, 9 Mar 2013 06:35:04 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7AA21F85CE for ; Sat, 9 Mar 2013 06:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1661; q=dns/txt; s=iport; t=1362839699; x=1364049299; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g/azhwRb3rBh8F6lWOAbjvkThQ0ZAy6crNV8jcy6N7Q=; b=EKPILFLcCtcMVGccqP21fjwA2D0khsMnFpG2wMAUMeyjm3Rem62UbI46 3kYaNtE39b0U8caVlp4h0Jj5T5esGSW63YNdTufsGUOoRlpupsKyA0FzI O/YmGU7UYlNg/ErlLqQV0auNHSAkndOC/0wO9pZrEwgzJtKZOFwRcrrbi M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADBIO1GtJXG8/2dsb2JhbABDxGGBXxZ0gi0BAQECAjo/EAIBCBgeEDIlAgQOBYgTDLtIjwwCBYJfYQOWVJBzgwo X-IronPort-AV: E=Sophos;i="4.84,813,1355097600"; d="scan'208";a="185649619" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 09 Mar 2013 14:34:59 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r29EYx8t014911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Mar 2013 14:34:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Sat, 9 Mar 2013 08:34:58 -0600 From: "Cullen Jennings (fluffy)" To: Peter Saint-Andre Thread-Topic: [dispatch] IETF-86 DISPATCH Topics Thread-Index: AQHOFT0/MgZ5CihkSUWRNGIN85IIH5iZkzYAgAElNgCAAefFAIAA2+EN Date: Sat, 9 Mar 2013 14:34:58 +0000 Message-ID: <49F58715-3404-4A96-B40F-B04E7BB481F2@cisco.com> References: <5137AC9E.5080608@stpeter.im> , <513A3BC0.9050809@stpeter.im> In-Reply-To: <513A3BC0.9050809@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH , Richard Barnes , "rai-ads@tools.ietf.org" Subject: Re: [dispatch] IETF-86 DISPATCH Topics X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 14:35:05 -0000 Slides looked good to me On Mar 8, 2013, at 1:28 PM, "Peter Saint-Andre" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 3/7/13 7:22 AM, Mary Barnes wrote: >> Peter, >>=20 >> Thank you very much! I have uploaded to the proceedings:=20 >> https://datatracker.ietf.org/meeting/86/materials.html >>=20 >> Just let us know if you do make any changes so we can make sure >> and have the right version available. >=20 > I have corrected a few points in the slides and have uploaded them in > place at https://stpeter.im/files/ietf86-dispatch-sip-xmpp.pdf >=20 > Peter >=20 > - --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQIcBAEBAgAGBQJROjvAAAoJEOoGpJErxa2pOOIP/1Pvtd4w69iTOYUklCNZXYFT > 1GP9P+I5ghI1wSScPMS6nAdF3sP1zQq54VHq4d0pGlf3PGs7j3bjRhnufsdTcrRz > xHsxAeljyp2rhnSEuSEtbp/zIY78AukAMW/0VPKbERb2dbRcEZkFJ6aZUZb46Rdp > e+UYjgruGMsWuRf/Q1WX3P/wgce7CWN4JDnHoKYuee/LKxe3eMS85+Ku7BuUveBE > GhIZE+UpLSy8C4t3RhCq9pj56ZiyME9tefdckSIBGk6M3LAVxj+DFb8q+mfCnQTZ > a83qeQ35lBpMI4ZqUd48/yBSgHMXjaZrQrNVTzst+IlODsCtX3xNoXdVw50ZoC+j > jKk1ESiWzPm2spTEmyC0EBOYMmrRmcAi2sPwFLRM7GYNiioVPqapaSXxzhzQAecu > mNTRLVyAGXHCk5CQ88tymxdJ7A4GYLTB/4jHeJ3qOzSihSYw9mRcIzivQGDH0l8u > K/UIddh3bCDyjUDNghrdlW5zQgIeNpvcw0HKgnvb7V0RFfQ4694mbrasXIo6dKWc > s0ReJwQvhl9KeyERYeeBgrnEBt3b7qdmGCjEzbmqPLkUPxlg4m9HdaWbRjcRrvx9 > YkXxNCCerF/G1RFvFry7G7AcakO+g+0x7+UBIjLx+uZygXePdPVubVAODuDNzahI > /Rk/v67qKUh4IA7CEVAW > =3DN0mR > -----END PGP SIGNATURE----- From michaellundberg.ietf@gmail.com Sat Mar 9 16:29:03 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BC021F8721 for ; Sat, 9 Mar 2013 16:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 vbYL3+e9tZuD for ; Sat, 9 Mar 2013 16:29:02 -0800 (PST) Received: from mail-we0-x244.google.com (mail-we0-x244.google.com [IPv6:2a00:1450:400c:c03::244]) by ietfa.amsl.com (Postfix) with ESMTP id A13FC21F85B8 for ; Sat, 9 Mar 2013 16:29:02 -0800 (PST) Received: by mail-we0-f196.google.com with SMTP id t11so832933wey.7 for ; Sat, 09 Mar 2013 16:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=pZiOOnLfr43yafPm3BxRPrvm9BW9+El1j61pNMrLgtM=; b=gq418F10g0C3qMoIfe4qAF8mj1rwbiJj+Ia4M5gAGPx45yBjIOh3a2+/FDZT40cWT6 3ox1be2ZG3zzTRRo4ssFSHdqsyybG9HdCoEY57dSOvvSfkUskdbU1Dn6dAT0HVVrY6NL yrV5kFQh3AqB4Lk07U5DMcUQi7L5LgqDSTjCSt5UUo/c8Um84SRUu5i1c0jSoQ0L74KX 61Dkd44QmIpxOA9hK+TQY0CZJrwmc66PnsgngbQrfrZCictOkILQtU8/28TwYdPBwnjY S/CDXGUvJLiNgJhCoAJp4iN/y1AysefCE15xwESdGlRrUW6xE8WSZlIzOY00Q2P8G/UZ Grkw== MIME-Version: 1.0 X-Received: by 10.194.5.4 with SMTP id o4mr11734538wjo.40.1362875341669; Sat, 09 Mar 2013 16:29:01 -0800 (PST) Received: by 10.217.94.8 with HTTP; Sat, 9 Mar 2013 16:29:01 -0800 (PST) Date: Sat, 9 Mar 2013 19:29:01 -0500 Message-ID: From: Michael Lundberg To: dispatch@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [dispatch] Comments on draft-saintandre-sip-xmpp-presence-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 00:29:03 -0000 Peter, Thanks for resubmitting the SIP-XMPP presence I-D. I think this and the other documents are important as there are a lot of interworking issues today with XMPP and SIP/SIMPLE implementations, and I think these documents can help reduce some of those interworking challenges. In order to help ensure interworking between different implementations, I think Sections 5.2 and 5.3 need to have some stronger =91MUST=92 language instead of SHOULDs, MAYs, etc. This will enforce proper and complete mappings between implementations that conform to this document. While I don=92t think the document needs to enforce the use of the element mapping discussed in 5.2, I think if implementations are going to use the mapping, this document should enforce the use of a specific namespace and describe the mapping of values specified in RFC 6121 (i.e., away, dnd, chat, and xa). This will at least allow a minimum set of standard mappings between XMPP and SIP, which can be expanded on in future document(s). Section 5.3 could then also discuss how this mapping can be accomplished from SIP to XMPP if the SIP endpoints/devices support this same namespace. One of the big interworking challenges with today=92s implementations is the use of different namespaces given the extensibility of XML-based presence standards (e.g., PIDF, RPID), which allows individuals to create their own namespace. This flexibility is good for ingenuity, but problematic for interworking between different implementations. I think standardizing a basic set of common status information using a specific namespace is needed, and this document is a good place to do that. In my opinion, I do not think Section 6 should be part of this base document. While I like the idea of encapsulating the SIP information into the XMPP message, I think this content should be a consideration for implementing =91rich presence=92. As written, this method is only applicable for SIP to XMPP translation, and if the focus of this document is just =91basic=92 presence information interworking, the SIP to XMPP mapping in Section 5.3 already describes a method for how this can be accomplished. Regards, Michael From keith.drage@alcatel-lucent.com Sun Mar 10 10:25:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C856C21F8585 for ; Sun, 10 Mar 2013 10:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 g4eH2j5Yij5P for ; Sun, 10 Mar 2013 10:25:50 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id B7F8821F8415 for ; Sun, 10 Mar 2013 10:25:49 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2AHPlWI022264 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 10 Mar 2013 18:25:47 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 10 Mar 2013 18:25:46 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sun, 10 Mar 2013 18:25:45 +0100 From: "DRAGE, Keith (Keith)" To: "dispatch@ietf.org" Thread-Topic: Proposed charter for work on logging Thread-Index: Ac4LyOtf/7ujcRPHQoOZ6+wpJgfGIAR6wVFQ Date: Sun, 10 Mar 2013 17:25:45 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BF1BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [dispatch] Proposed charter for work on logging X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 17:25:50 -0000 Peter has suggested a minor modification to the charter text (which he also= plans to make to the abstract of the requirements document). SIP networks use signalling monitoring tools to diagnose user reported problem and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signalling will take between clients, and therefore impractical to monitor SIP signalling end-to-end. This work will provide for adding an indicator to the SIP protocol which can be used to mark signalling as of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. The change is in the 2nd paragraph, changing "subject to" to "of interest t= o". Regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: 15 February 2013 22:08 > To: dispatch@ietf.org > Subject: [dispatch] Proposed charter for work on logging >=20 > Peter Dawes has submitted >=20 > https://datatracker.ietf.org/doc/draft-dawes-dispatch-logme-reqs/ >=20 > as a set of requirements that will work with the session identifier > produced by the INSIPID working group to enable identification of loggabl= e > sessions. >=20 > The INIPID WG did consider this work, but considered it was out of scope > of the work they are currently chartered to do. >=20 > I propose the following scope for DISPATCH to consider based on the > Abstract of the above document. >=20 > SIP networks use signalling monitoring tools to diagnose user > reported problem and for regression testing if network or client > software is upgraded. As networks grow and become interconnected, > including connection via transit networks, it becomes impractical to > predict the path that SIP signalling will take between clients, and > therefore impractical to monitor SIP signalling end-to-end. >=20 > This work will provide for adding an indicator to the SIP > protocol which can be used to mark signalling as subject to logging. > Such marking will typically be applied as part of network testing > controlled by the network operator and not used in regular client > signalling. However, such marking can be carried end-to-end > including the SIP terminals, even if a session originates and > terminates in different networks. >=20 >=20 > Milestones >=20 > Dec 2013 Requirements for marking SIP sessions for logging to IESG > (Informational) > Mar 2014 Protocol for marking SIP sessions for logging to IESG > (Proposed standard) >=20 > I would note that the work does not necessarily need a new working group, > it could for example be an extension of the work of either the SIPCORE WG > or the INSIPID WG, but that is for the discussion to decide. >=20 > Your comments and proposals for revision are welcome. >=20 > For information there have been a number of previous documents on the > subject, but these might or might not form part of the proposed solution, > particularly given that some of them predate the INSIPID work. >=20 > http://tools.ietf.org/html/draft-dawes-sipping-debug-id-01 > http://tools.ietf.org/html/draft-dawes-sipping-debug-event-01 > http://tools.ietf.org/html/draft-kaithal-dispatch-sip-log-information-00 > http://tools.ietf.org/html/draft-dawes-sipping-debug-05 > http://tools.ietf.org/html/draft-dawes-dispatch-debug-00 > http://tools.ietf.org/html/draft-kaithal-sipclf-sip-log-information-00 >=20 >=20 > Regards >=20 > Keith > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@iii.ca Sun Mar 10 15:25:21 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC59C21F8480 for ; Sun, 10 Mar 2013 15:25:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7p5qC3JOfQO for ; Sun, 10 Mar 2013 15:25:20 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7158E21F873C for ; Sun, 10 Mar 2013 15:25:19 -0700 (PDT) Received: from [10.71.228.241] (unknown [208.180.59.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8A2AC509B8; Sun, 10 Mar 2013 18:25:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA921A0424@STNTEXCH01.cis.neustar.com> Date: Sun, 10 Mar 2013 17:25:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55A5A9A87506CB4BA580BF9D531957DA921A0424@STNTEXCH01.cis.neustar.com> To: "Peterson, Jon" X-Mailer: Apple Mail (2.1499) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] terq charter revision X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 22:25:21 -0000 I will probably miss the dispatch meeting at IETF 86 but I'm in favor of = chartering this work.=20 On Mar 7, 2013, at 5:27 PM, "Peterson, Jon" = wrote: >=20 > Based on the comments previously received, this is a slight revision = to the TeRQ charter. The fundamentals here though are pretty much = unchanged: the plan is to do the framework and information model = document and one binding document, rechartering if there is interest in = doing any further binding documents. >=20 > Jon Peterson > NeuStar, Inc. >=20 > --- >=20 > Title: Telephony-Related Queries > Acronym: terq > Area: Real-time Applications and Infrastructure > Area Director: TBD > Chair(s): TBD > Mailing address: TBD (currently dispatch@ietf.org) >=20 > Description of Working Group >=20 > Several IETF efforts have studied the handling of telephone numbers on = the Internet. For example, the ENUM working group specified a DNS-based = approach to transforming telephone numbers into URIs; the DRINKS working = group produced a provisioning system suitable for populating Internet = directories of telephone numbers. The overall goal of this work has been = to migrate the routing and directory functions of the telephone network = onto the Internet, in order to simplify the implementation of Internet = telephony and reduce the Internet's reliance on the infrastructure of = the public switched telephone network. Ultimately, the requirements for = this project diverged significantly from the original architecture and = applicability of ENUM. Moreover, in the twelve years since ENUM was = first chartered, Internet telephony has changed a great deal. As one = example, today web-based applications are becoming more significant to = Internet telephony, as are intelligent mobile devices. In these env > ironments, there exists a capacity for richer queries and responses, = as well as more sophisticated application logic to process requests, but = also tougher security requirements. As such, this working group = reconsiders the migration of routing and directory functions from the = telephone network to the Internet by generalizing the base semantics of = queries and responses in an abstract framework, and then defining = possible transports and encodings for these messages. >=20 > The components of the chartered work include: >=20 > 1. A framework and information model for the construction queries and = responses. The information model will provide an abstract description of = the semantics of the various elements and attributes that make up TeRQ = messages. The framework will further establish the semantics of TeRQ = transactions, describe how responses are matched with queries, and give = an overview of the operation of the protocol. It will furthermore = describe the overall security model of TeRQ, including confidentiality = and access control measures necessary to preserve privacy. >=20 > 2. A process for specifying bindings for the information model, which = comprise transports and encodings. Transports specify the underlying = protocols that will encapsulate TeRQ queries and responses. This working = group is not chartered to define new underlying protocols, but will = specify how the transaction model of TeRQ maps onto these underlying = protocols. Potential underlying protocols include HTTP and DIAMETER. The = encoding determines how TeRQ elements and attributes will be rendered in = the object format carried by the transport; potential object formats = would include JSON and XML and well as lower-layer encodings. Binding = specifications must detail their implementation of the security and = privacy requirements defined in the framework. >=20 > 3. A set of one or more bindings compliant with the process described = in (2), which provide a concrete instantiation of the protocol. This = group will be initially chartered to create a single binding, though = other may be a potential subject for ongoing work after a rechart. These = bindings may accompany profiles that detail particular sets of = attributes or elements relevant to a given deployment. >=20 > The TeRQ working group will coordinate with ongoing work in the DRINKS = space in order to make sure that the TeRQ information model conforms = with the needs of provisioning systems. Whenever possible, TeRQ will = reuse existing IETF work. The syntax and semantics of telephone numbers, = for example, have been the subject of a great deal of previous IETF work = (notably RFC 3966), and the TeRQ working group will rely on this and = related prior work.=20 >=20 > Goals and Deliverables: >=20 > Aug 2013 Submit Framework for Telephony Related Queries as = Proposed Standard > Nov 2013 Submit one TeRQ Binding as Proposed Standard > Feb 2013 Recharter if additional bindings are required > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@iii.ca Sun Mar 10 15:28:21 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA1521F8610 for ; Sun, 10 Mar 2013 15:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] 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 NJIUtSupcKrd for ; Sun, 10 Mar 2013 15:28:21 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3598021F8480 for ; Sun, 10 Mar 2013 15:28:21 -0700 (PDT) Received: from [10.71.228.241] (unknown [208.180.59.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 77C25509B8; Sun, 10 Mar 2013 18:28:20 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: Date: Sun, 10 Mar 2013 17:28:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1499) Cc: dispatch@ietf.org, stephane.cazeaux@orange.com Subject: Re: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 22:28:21 -0000 On Mar 6, 2013, at 11:00 AM, I=F1aki Baz Castillo wrote: > --------------- > m=3Dapplication 50000 TCP/TLS/BFCP * > a=3Dsetup:passive > a=3Dconnection:new > a=3Dfingerprint:SHA-1 \ > 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB > a=3Dfloorctrl:s-only > a=3Dconfid:4321 > a=3Duserid:1234 > a=3Dfloorid:1 m-stream:10 > a=3Dfloorid:2 m-stream:11 > m=3Daudio 50002 RTP/AVP 0 > a=3Dlabel:10 > m=3Dvideo 50004 RTP/AVP 31 > a=3Dlabel:11 > --------------- >=20 > Well, I strongly hope nobody plans to pass such an SDP to a WebRTC > RTCPeerConnection constructor since it will die. If an offer such s that got passed into a browser and it died, I would = view that as a bug. Of course I don' expect it to implement BFCP but I = expect the newer to correctly reject it. Actually, if there was any = string you could pass in from JS to the browser that caused the browser = to die, I would consider that a bug.=20 From fluffy@iii.ca Sun Mar 10 15:32:17 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937DD21F8742 for ; Sun, 10 Mar 2013 15:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 YDgGqZA5yceo for ; Sun, 10 Mar 2013 15:32:16 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B4B2B21F8629 for ; Sun, 10 Mar 2013 15:32:16 -0700 (PDT) Received: from [10.71.228.241] (unknown [208.180.59.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 34944509B5; Sun, 10 Mar 2013 18:32:16 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: <51367196.8090204@alum.mit.edu> Date: Sun, 10 Mar 2013 17:32:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <5136397F.3000002@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828047C73EC@xmb-aln-x08.cisco.com> <51365D0D.80202@alum.mit.edu> <51366348.3080302@gmail.com> <51367196.8090204@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1499) Cc: dispatch@ietf.org Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 22:32:17 -0000 It seems to me an important point on this is thinking about where BFCP = is used. Does it need to be P2P or can it just form a web socket to some = server. The API for web sockets and data channels is very close to the = same so the important feature is do you need the P2P capabilities of = data channel or not.=20 On Mar 5, 2013, at 4:28 PM, Paul Kyzivat wrote: > On 3/6/13 5:27 AM, Sergio Garcia Murillo wrote: >> El 05/03/2013 22:01, Paul Kyzivat escribi=F3: >>> On 3/6/13 3:51 AM, Charles Eckel (eckelcu) wrote: >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On >>>>> Behalf Of Paul Kyzivat >>>>> Sent: Tuesday, March 05, 2013 10:29 AM >>>>> To: I=F1aki Baz Castillo >>>>> Cc: dispatch@ietf.org; stephane.cazeaux@orange.com >>>>> Subject: Re: [dispatch] Remapping existing protocols for web = usage: >>>>> websockets or data channels? >>>>>=20 >>>>> I=F1aki, >>>>>=20 >>>>> In the specific case of bfcp, it is likely that one end will = always be >>>>> on a server. (Its unlikely that one would want to use bfcp in a = pt-pt >>>>> call between two web clients.) So that makes websockets suitable, = where >>>>> it would be less so for something that might be used between two = web >>>>> clients. >>>>=20 >>>> I disagree, in that even in a pt to pt call, BFCP is used to >>>> negotiate which endpoint is allowed to transmit content. The >>>> offer/answer exchange is used to determine which end should be the >>>> BFCP server and which should be the BFCP client. In the case of a >>>> conference, the conference server typically tries to be the BFCP >>>> server and the conference participants happily let it. >>>=20 >>> Good to have a comment from someone who actually knows about bfcp! >>>=20 >>> In that case, websockets wouldn't work between two rtcweb clients >>> without a relay in the middle, right? >>=20 >> But on the other side, if a browser doesn't support webrtc, you won't = be >> able to use BFCP. Typical situation is when you are connecting to the >> conference simultaneously from a phone/videophone and also connected = in >> your PC via web. >>=20 >> Also, adding datachannels support to a server just to support BFCP on >> web clients is an absolute overkill. >=20 > What are we trying to accomplish here? >=20 > If we want to support use of BFCP by an RTCWEB client, then presumably = the browser supporting that client supports RTCWEB. So it could use BFCP = over data channel. Or we could use websocket. >=20 > If we want to support a web client that is not an RTCWEB client, and = running with a web browser that doesn't support RTCWEB, then we could = use BFCP over websocket. But then two of those couldn't talk to one = another - they could only talk to a server. That would work with = conference servers that support BFCP over websocket. >=20 > The main impact seems to be whether the server prefers to support = websocket or data channel for BFCP. Maybe it would be a bit easier. But = some will be doing data channels anyway. (E.g. for CLUE.) >=20 > Thanks, > Paul >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From ibc@aliax.net Sun Mar 10 15:38:43 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3892321F878F for ; Sun, 10 Mar 2013 15:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 MZbMHoMNd05w for ; Sun, 10 Mar 2013 15:38:42 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 78A7021F8758 for ; Sun, 10 Mar 2013 15:38:42 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id j8so687606qah.0 for ; Sun, 10 Mar 2013 15:38:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=nDnnwNPt3eMl6AS+edJgfpE1iT6i4O99fuA1adsk50I=; b=IwhYNHzCeWXfI8cP2IgTRRY+L2M3TlhE1aJ51vedHqN3xqWNi1pD80X6T+005IU+cS ePDnXqwjwVvb7Iw7ugcVeTg+q1yGczq1Uct01z/N/J7yv0Cb6wDzGLI8c0VN45wJbb0J x1warQFZ8qS9jTqQlGHwKshtALrl5K0JGsZuuTB8SpVzG1NZ1Yv8FIw3xNz+yH0/C9fs NeKSGFp4rdKMY9/8VUMOjQAy8ukGw1+1PpAhOXaWqwfSp6cqVzgX6SaEj3G64FL+wMmO 9kg+EQFYuIAGld+ypeidYyHjYD1WbcEOqajKGGXbgNUZgQHJhYlC/cx6jmJohyauZoc6 VftA== X-Received: by 10.224.33.140 with SMTP id h12mr14562665qad.73.1362955121841; Sun, 10 Mar 2013 15:38:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.12.233 with HTTP; Sun, 10 Mar 2013 15:38:21 -0700 (PDT) In-Reply-To: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 10 Mar 2013 23:38:21 +0100 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlkzhIdg6Mwc4Z85+q6XBSdIPKDumef3TX63emhJd3VfelLycY25vvJErI0xsycoqtL8R+U Cc: dispatch@ietf.org, stephane.cazeaux@orange.com Subject: Re: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 22:38:43 -0000 2013/3/10 Cullen Jennings : > If an offer such s that got passed into a browser and it died, I would vi= ew that as a bug. Of course I don' expect it to implement BFCP but I expect= the newer to correctly reject it. Actually, if there was any string you co= uld pass in from JS to the browser that caused the browser to die, I would = consider that a bug. Probably it's a bug as you say. But my question is: will browser vendors allow passing "strange" stuff into the SDP? Taking into account the SDP format complexity and the issues already being discussed rigth now in rtcweb WG about SDP usage, I don't expect that such an exotic SDP will work. --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Sun Mar 10 15:46:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3EB21F8807 for ; Sun, 10 Mar 2013 15:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ZXkB8npv+41Z for ; Sun, 10 Mar 2013 15:46:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECB521F8804 for ; Sun, 10 Mar 2013 15:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1066; q=dns/txt; s=iport; t=1362955609; x=1364165209; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3R6MzNleYWv3NtdAJyXoSUZbSHBIqhVCkJv9JYRveBY=; b=PxWMWCPH7cygcbn1PbQoh5Ze5Rj0mX1paPOtXeSzXuczn2/XnsbFV4ON 2LHtuIDZrSnxbq/+R1lweceQxQu1cJ1PtWzyIBD96OsxDUWCaWBp3WyjW CXM+Mb4aJ2Fv9wSF/ourSVbaJcBvmaEJhPnRJz6V7xV6iEY1nVZf2OoZm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACIMPVGtJV2c/2dsb2JhbAA5CcREgUsWdIImAQEBBDo/EAIBCBgKFBAyJQIEDgUIiAsMu18EjVSBBwIxB4JfYQOnSoMKgig X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208";a="185869143" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 10 Mar 2013 22:46:49 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2AMkmVl018825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Mar 2013 22:46:48 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 17:46:38 -0500 From: "Cullen Jennings (fluffy)" To: Peter Saint-Andre Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity Thread-Index: AQHOGAsUJhdVcbJHkUyhphnvwmWC1JiVOwO4gAEPdoCAAAYFAIAAD2CAgAmDrwA= Date: Sun, 10 Mar 2013 22:46:37 +0000 Message-ID: References: <51102D21.10503@stpeter.im> <5134F00F.9030301@stpeter.im> <51350201.6090507@stpeter.im> In-Reply-To: <51350201.6090507@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.3.145] Content-Type: text/plain; charset="us-ascii" Content-ID: <7729557BF7318A41AED511020AE1751B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 22:46:50 -0000 On Mar 4, 2013, at 2:20 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 3/4/13 12:25 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> Peter, >>=20 >> Today, there is no registry for the "purpose" values in the >> Call-Info header. Mary and I have an open issue around this in the >> following draft, as we would like to register a "ccmp" value.=20 >> https://datatracker.ietf.org/doc/draft-yusef-dispatch-ccmp-indication/?i= nclude_text=3D1 >>=20 >> Please, keep us posted on your discussion with IANA on this. >=20 > Thinking about this further, I realize we might need a new, very short > I-D that creates the registry. I think this is something that one of > us could write in an hour. I'd be happy to do that before the I-D > submission window opens again. >=20 > Peter Thank you - I think that this was an oversight in 3261 that it failed to de= fine it and short draft could clean that up. If the ADs are OK with it, th= is seems like a good draft to be AD sponsored.=20 From fluffy@cisco.com Sun Mar 10 15:46:51 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FB021F8807 for ; Sun, 10 Mar 2013 15:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 iKCdn2m895km for ; Sun, 10 Mar 2013 15:46:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C525F21F8804 for ; Sun, 10 Mar 2013 15:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2186; q=dns/txt; s=iport; t=1362955611; x=1364165211; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PwUQaDvgNjG4gc9VLb3PYOYDv8+Oho3cBkUbiK1+JmI=; b=F8gvtq2t6klDuIz+0y961CSplqLogN8ulbS1+RorVdKVwSEL6jlT4bv2 vJi9mmoaqhkQb18IgRmxFu5KnJTtijPIfTH2FbHc7MB7ilcrgSSb/V9Xd 3RYvhU1SXGQPf2VjDdcXB+LKEjZM+B7PRSh5aG4FuBD7p8vUQ/cNhv3B/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACoNPVGtJXG+/2dsb2JhbAA4CsREgUsWdIImAQEBAwE6PxACAQgVDRQFCzIlAgQOBQiIBQa7c41TgQomCweCX2EDp0qBVIE2gWokGg X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208";a="185847792" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 10 Mar 2013 22:46:43 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2AMkhZW030645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Mar 2013 22:46:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 17:46:43 -0500 From: "Cullen Jennings (fluffy)" To: "Dale R. Worley" Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQHOGRXcMMCAzJYzhkOmkNSi4UyFuJif4eIA Date: Sun, 10 Mar 2013 22:46:42 +0000 Message-ID: References: <50ABBAD6.9050103@gmail.com> <201303042021.r24KLXjF3047185@shell01.TheWorld.com> In-Reply-To: <201303042021.r24KLXjF3047185@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.3.145] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 22:46:51 -0000 Dale, thanks for parsing that clarifying it. Yes that is what I meant.=20 On Mar 4, 2013, at 2:21 PM, Dale R. Worley wrote: >> From: "Cullen Jennings (fluffy)" >>=20 >> But the instance ID is in a register sent to trusted providers that >> know the users name, credentials etc and can be send in an encrypted >> channel. This is a bit different it that it goes to other users. The >> analysis is not at the same.=20 >=20 > This is a bit awkward to read, but I believe that your intention is: >=20 > When the instance ID is in a REGISTER, it is sent to trusted > providers that know the user's name, credentials, etc. already, > and it can be sent in an encrypted channel. This proposal (i.e., > draft-allen-dispatch-imei-urn-as-instanceid) is different in that > the the GRUU containing the IMEI is sent to other users. The > analysis is not the same. >=20 > Please correct me if I'm wrong. >=20 > But assuming that I'm correct: Yes, > draft-allen-dispatch-imei-urn-as-instanceid results in the IMEI being > sent to other users, embedded in the Contact GRUU. And the privacy > analysis of that is different from that of a REGISTER. >=20 > The user that receives the IMEI-containing URI does not have a > database mapping the IMEI to the user's name or other data. (Or at > least, I don't expect the service providers to make their database > available to subscribers.) >=20 > So the IMEI-containing URI is reduced from a personal identifier to a > "constant user fingerprint", an identifier that is associated with > just one person, but anyone who wants to make use of that fact has to > figure out themselves which person it is. >=20 > And that is the same as any with other GRUU. If one's phone is using > a GRUU, any conversant can record the GRUU and one's name, and use it > to identify further calls from one's self. >=20 > Of course, if the user intends anonymity, the user can cause the UA to > obtain a temporary GRUU which is not a constant user fingerprint, as > is implied by section 8 of the draft. We've already worked through > this problem. >=20 > Dale From stpeter@stpeter.im Sun Mar 10 19:28:46 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E8311E80D3 for ; Sun, 10 Mar 2013 19:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 iODHz3It6lcM for ; Sun, 10 Mar 2013 19:28:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0050011E80A6 for ; Sun, 10 Mar 2013 19:28:45 -0700 (PDT) Received: from [192.168.6.47] (unknown [64.134.177.171]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5C740406A8; Sun, 10 Mar 2013 20:37:13 -0600 (MDT) Message-ID: <513D415B.7060505@stpeter.im> Date: Sun, 10 Mar 2013 22:28:43 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <51102D21.10503@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Emil Ivov Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 02:28:47 -0000 On 3/3/13 8:12 AM, Cullen Jennings (fluffy) wrote: > > If you don't want to do the vcard but just want the xmpp address directly, I'd probably suggest something like > > Call-Info: ;purpose=impp > > To just indicate that the URL provided the IM and Presence service for that user > > RFC 3261 section 20.9 says that the IANA section of 3261 will define how to add a new purpose but as far as I can tell it does not. However, the IANA SIP registry for the URI purpose at > > http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-13 > > is just spec required so I think think you might be able to trivial add a "impp" purpose. https://datatracker.ietf.org/doc/draft-saintandre-impp-call-info/ Peter -- Peter Saint-Andre https://stpeter.im/ From hgs@cs.columbia.edu Sun Mar 10 19:41:31 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31AA21F8614 for ; Sun, 10 Mar 2013 19:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] 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 m0smN-cwhFYm for ; Sun, 10 Mar 2013 19:41:30 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id E26FA21F8528 for ; Sun, 10 Mar 2013 19:41:29 -0700 (PDT) Received: from [192.168.144.125] ([98.79.94.25]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r2B2fQLV005073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 10 Mar 2013 22:41:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henning Schulzrinne In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA921A0424@STNTEXCH01.cis.neustar.com> Date: Sun, 10 Mar 2013 19:30:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55A5A9A87506CB4BA580BF9D531957DA921A0424@STNTEXCH01.cis.neustar.com> To: "Peterson, Jon" X-Mailer: Apple Mail (2.1499) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] terq charter revision X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 02:41:31 -0000 Two questions/comments: (1) It is not quite clear whether the scope is restricted to retrieval = ("GET") or also updates by authorized entities ("PUT"). For HTTP, it = seems relatively straightforward to specify both, less so for DIAMETER, = but I don't see much of a problem with having several retrieval = mechanisms. (2) There is some relationship to the whois retrieval work, I believe. = This should at least be explored. Henning On Mar 7, 2013, at 6:27 PM, "Peterson, Jon" = wrote: >=20 > Based on the comments previously received, this is a slight revision = to the TeRQ charter. The fundamentals here though are pretty much = unchanged: the plan is to do the framework and information model = document and one binding document, rechartering if there is interest in = doing any further binding documents. >=20 > Jon Peterson > NeuStar, Inc. >=20 > --- >=20 > Title: Telephony-Related Queries > Acronym: terq > Area: Real-time Applications and Infrastructure > Area Director: TBD > Chair(s): TBD > Mailing address: TBD (currently dispatch@ietf.org) >=20 > Description of Working Group >=20 > Several IETF efforts have studied the handling of telephone numbers on = the Internet. For example, the ENUM working group specified a DNS-based = approach to transforming telephone numbers into URIs; the DRINKS working = group produced a provisioning system suitable for populating Internet = directories of telephone numbers. The overall goal of this work has been = to migrate the routing and directory functions of the telephone network = onto the Internet, in order to simplify the implementation of Internet = telephony and reduce the Internet's reliance on the infrastructure of = the public switched telephone network. Ultimately, the requirements for = this project diverged significantly from the original architecture and = applicability of ENUM. Moreover, in the twelve years since ENUM was = first chartered, Internet telephony has changed a great deal. As one = example, today web-based applications are becoming more significant to = Internet telephony, as are intelligent mobile devices. In these env > ironments, there exists a capacity for richer queries and responses, = as well as more sophisticated application logic to process requests, but = also tougher security requirements. As such, this working group = reconsiders the migration of routing and directory functions from the = telephone network to the Internet by generalizing the base semantics of = queries and responses in an abstract framework, and then defining = possible transports and encodings for these messages. >=20 > The components of the chartered work include: >=20 > 1. A framework and information model for the construction queries and = responses. The information model will provide an abstract description of = the semantics of the various elements and attributes that make up TeRQ = messages. The framework will further establish the semantics of TeRQ = transactions, describe how responses are matched with queries, and give = an overview of the operation of the protocol. It will furthermore = describe the overall security model of TeRQ, including confidentiality = and access control measures necessary to preserve privacy. >=20 > 2. A process for specifying bindings for the information model, which = comprise transports and encodings. Transports specify the underlying = protocols that will encapsulate TeRQ queries and responses. This working = group is not chartered to define new underlying protocols, but will = specify how the transaction model of TeRQ maps onto these underlying = protocols. Potential underlying protocols include HTTP and DIAMETER. The = encoding determines how TeRQ elements and attributes will be rendered in = the object format carried by the transport; potential object formats = would include JSON and XML and well as lower-layer encodings. Binding = specifications must detail their implementation of the security and = privacy requirements defined in the framework. >=20 > 3. A set of one or more bindings compliant with the process described = in (2), which provide a concrete instantiation of the protocol. This = group will be initially chartered to create a single binding, though = other may be a potential subject for ongoing work after a rechart. These = bindings may accompany profiles that detail particular sets of = attributes or elements relevant to a given deployment. >=20 > The TeRQ working group will coordinate with ongoing work in the DRINKS = space in order to make sure that the TeRQ information model conforms = with the needs of provisioning systems. Whenever possible, TeRQ will = reuse existing IETF work. The syntax and semantics of telephone numbers, = for example, have been the subject of a great deal of previous IETF work = (notably RFC 3966), and the TeRQ working group will rely on this and = related prior work.=20 >=20 > Goals and Deliverables: >=20 > Aug 2013 Submit Framework for Telephony Related Queries as = Proposed Standard > Nov 2013 Submit one TeRQ Binding as Proposed Standard > Feb 2013 Recharter if additional bindings are required > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From pkyzivat@alum.mit.edu Sun Mar 10 19:43:33 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E1E21F8528 for ; Sun, 10 Mar 2013 19:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.063 X-Spam-Level: * X-Spam-Status: No, score=1.063 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 EA8fqPCoGgpn for ; Sun, 10 Mar 2013 19:43:33 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 116D821F872D for ; Sun, 10 Mar 2013 19:43:32 -0700 (PDT) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta12.emeryville.ca.mail.comcast.net with comcast id A1cr1l00B0lTkoCAC2jY6b; Mon, 11 Mar 2013 02:43:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2001:df8:0:128:1d9f:4522:3569:ca14]) by omta04.emeryville.ca.mail.comcast.net with comcast id A2jX1l00E4B9e0B8Q2jXX5; Mon, 11 Mar 2013 02:43:32 +0000 Message-ID: <513D44D3.7010204@alum.mit.edu> Date: Mon, 11 Mar 2013 10:43:31 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Cullen Jennings References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <5136397F.3000002@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828047C73EC@xmb-aln-x08.cisco.com> <51365D0D.80202@alum.mit.edu> <51366348.3080302@gmail.com> <51367196.8090204@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362969812; bh=opFzyghmeGflWyHZ29jXpX1o6fQ1m+EraAt/UNGXclE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RQj8WZ6PtNIyfYdMe4y8FjskNxquW0PM7nNFG4moLgkk5tbo4xPqIybQVdmyRM6xW lyi/eXn87mD6PM3vuek2BaqbfTmCt75irr14erI9+ADBkhrEZaMRpwdiCzs20W8+sq iNF1lMswkZibdKMqiq4QSH3EKWSPjjyW3ULvmfyzljQk/YJhhM/UYxi1fyjnkJmCBZ IxQpkn9SrFA+F4tlJLKCZMiSp9un2SS4vxN3ssJdr8ctCJ/hsGpTjVMyslbR3nX93t GdMAVjLIiBxrXxNxRdDWB5/oJiQa/igdqh7C+NULx08vRdah4xN0C6qc7UeDJX5Z1t BWmYTCg5T50hQ== Cc: dispatch@ietf.org Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 02:43:33 -0000 On 3/11/13 6:32 AM, Cullen Jennings wrote: > > It seems to me an important point on this is thinking about where BFCP is used. Does it need to be P2P or can it just form a web socket to some server. The API for web sockets and data channels is very close to the same so the important feature is do you need the P2P capabilities of data channel or not. I'm not a bfcp expert. ISTM that it is most likely to be used with a media server in a conference. But when I said that I got feedback that it may also be used in a p2p environment. I don't know if that is real, or theoretical. Thanks, Paul > On Mar 5, 2013, at 4:28 PM, Paul Kyzivat wrote: > >> On 3/6/13 5:27 AM, Sergio Garcia Murillo wrote: >>> El 05/03/2013 22:01, Paul Kyzivat escribió: >>>> On 3/6/13 3:51 AM, Charles Eckel (eckelcu) wrote: >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>>>> Behalf Of Paul Kyzivat >>>>>> Sent: Tuesday, March 05, 2013 10:29 AM >>>>>> To: Iñaki Baz Castillo >>>>>> Cc: dispatch@ietf.org; stephane.cazeaux@orange.com >>>>>> Subject: Re: [dispatch] Remapping existing protocols for web usage: >>>>>> websockets or data channels? >>>>>> >>>>>> Iñaki, >>>>>> >>>>>> In the specific case of bfcp, it is likely that one end will always be >>>>>> on a server. (Its unlikely that one would want to use bfcp in a pt-pt >>>>>> call between two web clients.) So that makes websockets suitable, where >>>>>> it would be less so for something that might be used between two web >>>>>> clients. >>>>> >>>>> I disagree, in that even in a pt to pt call, BFCP is used to >>>>> negotiate which endpoint is allowed to transmit content. The >>>>> offer/answer exchange is used to determine which end should be the >>>>> BFCP server and which should be the BFCP client. In the case of a >>>>> conference, the conference server typically tries to be the BFCP >>>>> server and the conference participants happily let it. >>>> >>>> Good to have a comment from someone who actually knows about bfcp! >>>> >>>> In that case, websockets wouldn't work between two rtcweb clients >>>> without a relay in the middle, right? >>> >>> But on the other side, if a browser doesn't support webrtc, you won't be >>> able to use BFCP. Typical situation is when you are connecting to the >>> conference simultaneously from a phone/videophone and also connected in >>> your PC via web. >>> >>> Also, adding datachannels support to a server just to support BFCP on >>> web clients is an absolute overkill. >> >> What are we trying to accomplish here? >> >> If we want to support use of BFCP by an RTCWEB client, then presumably the browser supporting that client supports RTCWEB. So it could use BFCP over data channel. Or we could use websocket. >> >> If we want to support a web client that is not an RTCWEB client, and running with a web browser that doesn't support RTCWEB, then we could use BFCP over websocket. But then two of those couldn't talk to one another - they could only talk to a server. That would work with conference servers that support BFCP over websocket. >> >> The main impact seems to be whether the server prefers to support websocket or data channel for BFCP. Maybe it would be a bit easier. But some will be doing data channels anyway. (E.g. for CLUE.) >> >> Thanks, >> Paul >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > From eckelcu@cisco.com Sun Mar 10 21:01:33 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A95B21F88CC for ; Sun, 10 Mar 2013 21:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PYz3OLLnRvvl for ; Sun, 10 Mar 2013 21:01:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 70C8421F8763 for ; Sun, 10 Mar 2013 21:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4556; q=dns/txt; s=iport; t=1362974492; x=1364184092; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EalLsDnt5pInHN6kmc23IIMPyv3OOHDZrGYZNwVyVqE=; b=RqmfMgeGeSr68kg8qBQW2yyYw4cFD7s96iuPMFhPH2P9v47CMe7HCUI5 Z/TJ3xvS/jh0j+6Lr1sFNv2kfYPS3T8153GtWWDs8HBDpNWj0F/ary1P6 AT698IctIC9oXIH07qLGF2zSaTQUM4/O08rEi4V50uSu+RU89lD/D+L3N M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAB9WPVGtJXG9/2dsb2JhbABDDsQ9gU8WdIIkAQEBBAEBAWUDAwsMBAIBCA4DBAEBAQodBycLFAkIAgQBDQUIiAsMvBAEjl0mCwcGgllhA4g8nw6BVHc/gig X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208";a="185926888" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 11 Mar 2013 04:01:32 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2B41Vba015563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 04:01:31 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 23:01:31 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , Cullen Jennings Thread-Topic: [dispatch] Remapping existing protocols for web usage: websockets or data channels? Thread-Index: AQHOHgI8Q2dPNz7rtU2NwtrbDcrYkZif12Ug Date: Mon, 11 Mar 2013 04:01:31 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047CC2D1@xmb-aln-x08.cisco.com> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <512A8982.3080809@alum.mit.edu> <5136397F.3000002@alum.mit.edu> <92B7E61ADAC1BB4F941F943788C08828047C73EC@xmb-aln-x08.cisco.com> <51365D0D.80202@alum.mit.edu> <51366348.3080302@gmail.com> <51367196.8090204@alum.mit.edu> <513D44D3.7010204@alum.mit.edu> In-Reply-To: <513D44D3.7010204@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.7] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Remapping existing protocols for web usage: websockets or data channels? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 04:01:33 -0000 For SIP based video conference, BFCP is required or else the second video m= -line for content sharing will not be setup. This is true for an endpoint c= onnecting to a conference server but also for two endpoints connecting to e= ach other.=20 Cheers, Charles > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Sunday, March 10, 2013 10:44 PM > To: Cullen Jennings > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Remapping existing protocols for web usage: > websockets or data channels? >=20 > On 3/11/13 6:32 AM, Cullen Jennings wrote: > > > > It seems to me an important point on this is thinking about where BFCP = is > used. Does it need to be P2P or can it just form a web socket to some ser= ver. > The API for web sockets and data channels is very close to the same so th= e > important feature is do you need the P2P capabilities of data channel or = not. >=20 > I'm not a bfcp expert. ISTM that it is most likely to be used with a > media server in a conference. But when I said that I got feedback that > it may also be used in a p2p environment. I don't know if that is real, > or theoretical. >=20 > Thanks, > Paul >=20 > > On Mar 5, 2013, at 4:28 PM, Paul Kyzivat wrote: > > > >> On 3/6/13 5:27 AM, Sergio Garcia Murillo wrote: > >>> El 05/03/2013 22:01, Paul Kyzivat escribi=F3: > >>>> On 3/6/13 3:51 AM, Charles Eckel (eckelcu) wrote: > >>>>>> -----Original Message----- > >>>>>> From: dispatch-bounces@ietf.org [mailto:dispatch- > bounces@ietf.org] On > >>>>>> Behalf Of Paul Kyzivat > >>>>>> Sent: Tuesday, March 05, 2013 10:29 AM > >>>>>> To: I=F1aki Baz Castillo > >>>>>> Cc: dispatch@ietf.org; stephane.cazeaux@orange.com > >>>>>> Subject: Re: [dispatch] Remapping existing protocols for web usage= : > >>>>>> websockets or data channels? > >>>>>> > >>>>>> I=F1aki, > >>>>>> > >>>>>> In the specific case of bfcp, it is likely that one end will alway= s be > >>>>>> on a server. (Its unlikely that one would want to use bfcp in a pt= -pt > >>>>>> call between two web clients.) So that makes websockets suitable, > where > >>>>>> it would be less so for something that might be used between two > web > >>>>>> clients. > >>>>> > >>>>> I disagree, in that even in a pt to pt call, BFCP is used to > >>>>> negotiate which endpoint is allowed to transmit content. The > >>>>> offer/answer exchange is used to determine which end should be the > >>>>> BFCP server and which should be the BFCP client. In the case of a > >>>>> conference, the conference server typically tries to be the BFCP > >>>>> server and the conference participants happily let it. > >>>> > >>>> Good to have a comment from someone who actually knows about > bfcp! > >>>> > >>>> In that case, websockets wouldn't work between two rtcweb clients > >>>> without a relay in the middle, right? > >>> > >>> But on the other side, if a browser doesn't support webrtc, you won't= be > >>> able to use BFCP. Typical situation is when you are connecting to the > >>> conference simultaneously from a phone/videophone and also > connected in > >>> your PC via web. > >>> > >>> Also, adding datachannels support to a server just to support BFCP on > >>> web clients is an absolute overkill. > >> > >> What are we trying to accomplish here? > >> > >> If we want to support use of BFCP by an RTCWEB client, then presumably > the browser supporting that client supports RTCWEB. So it could use BFCP > over data channel. Or we could use websocket. > >> > >> If we want to support a web client that is not an RTCWEB client, and > running with a web browser that doesn't support RTCWEB, then we could > use BFCP over websocket. But then two of those couldn't talk to one > another - they could only talk to a server. That would work with conferen= ce > servers that support BFCP over websocket. > >> > >> The main impact seems to be whether the server prefers to support > websocket or data channel for BFCP. Maybe it would be a bit easier. But > some will be doing data channels anyway. (E.g. for CLUE.) > >> > >> Thanks, > >> Paul > >> > >> _______________________________________________ > >> 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 ietf@meetecho.com Sun Mar 10 21:03:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F262621F8923 for ; Sun, 10 Mar 2013 21:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.644 X-Spam-Level: X-Spam-Status: No, score=-0.644 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 KuoAqMRZ4hHV for ; Sun, 10 Mar 2013 21:03:50 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg228.aruba.it [62.149.158.228]) by ietfa.amsl.com (Postfix) with ESMTP id 2899E21F8916 for ; Sun, 10 Mar 2013 21:03:49 -0700 (PDT) Received: from meetecho ([130.129.6.44]) by smtpcmd04.ad.aruba.it with bizsmtp id A43m1l00U0wzZHu0143oie; Mon, 11 Mar 2013 05:03:49 +0100 Date: Mon, 11 Mar 2013 00:03:17 -0700 (PDT) From: Meetecho Team To: dispatch@ietf.org Message-ID: <24813348.5.1362985397426.JavaMail.root@meetecho> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4_33228489.1362985397425" Subject: [dispatch] Meetecho support for DISPATCH session X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 04:03:51 -0000 ------=_Part_4_33228489.1362985397425 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the DISPATCH WG meeting session. Access to the on-line session (including audio and video streams) will be available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/dispatch The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_4_33228489.1362985397425-- From dschwartz@xconnect.net Sun Mar 10 23:03:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F193C21F8942 for ; Sun, 10 Mar 2013 23:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tVEYNxq8NFtA for ; Sun, 10 Mar 2013 23:03:23 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id C9ABD21F892F for ; Sun, 10 Mar 2013 23:03:23 -0700 (PDT) Received: from mail90-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE017.bigfish.com (10.236.130.80) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Mar 2013 06:03:23 +0000 Received: from mail90-co9 (localhost [127.0.0.1]) by mail90-co9-R.bigfish.com (Postfix) with ESMTP id 407819E0194; Mon, 11 Mar 2013 06:03:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.69; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0210HT005.eurprd02.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz98dI9371I1432Id799hzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dh8275fhz2fh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received-SPF: pass (mail90-co9: domain of xconnect.net designates 157.56.253.69 as permitted sender) client-ip=157.56.253.69; envelope-from=dschwartz@xconnect.net; helo=DB3PRD0210HT005.eurprd02.prod.outlook.com ; .outlook.com ; Received: from mail90-co9 (localhost.localdomain [127.0.0.1]) by mail90-co9 (MessageSwitch) id 1362981800891530_11502; Mon, 11 Mar 2013 06:03:20 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.228]) by mail90-co9.bigfish.com (Postfix) with ESMTP id CD0C26C005E; Mon, 11 Mar 2013 06:03:20 +0000 (UTC) Received: from DB3PRD0210HT005.eurprd02.prod.outlook.com (157.56.253.69) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Mar 2013 06:03:20 +0000 Received: from DB3PRD0210MB391.eurprd02.prod.outlook.com ([169.254.3.79]) by DB3PRD0210HT005.eurprd02.prod.outlook.com ([10.255.74.40]) with mapi id 14.16.0275.006; Mon, 11 Mar 2013 06:03:18 +0000 From: David Schwartz To: "Peterson, Jon" Thread-Topic: [dispatch] terq charter revision Thread-Index: AQHOG4uwJd1j/+51NEWjvHcnnYJWfpifhTGAgAB/95E= Date: Mon, 11 Mar 2013 06:03:17 +0000 Message-ID: <6CFEC5C0-88AE-4B21-9615-EC66926FBACD@xconnect.net> References: <55A5A9A87506CB4BA580BF9D531957DA921A0424@STNTEXCH01.cis.neustar.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [46.19.81.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: xconnect.net Cc: "dispatch@ietf.org" , Cullen Jennings Subject: Re: [dispatch] terq charter revision X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 06:03:26 -0000 +1 :D (sent from my mobile device) On Mar 11, 2013, at 12:25 AM, "Cullen Jennings" wrote: >=20 > I will probably miss the dispatch meeting at IETF 86 but I'm in favor of = chartering this work.=20 >=20 > On Mar 7, 2013, at 5:27 PM, "Peterson, Jon" wr= ote: >=20 >>=20 >> Based on the comments previously received, this is a slight revision to = the TeRQ charter. The fundamentals here though are pretty much unchanged: t= he plan is to do the framework and information model document and one bindi= ng document, rechartering if there is interest in doing any further binding= documents. >>=20 >> Jon Peterson >> NeuStar, Inc. >>=20 >> --- >>=20 >> Title: Telephony-Related Queries >> Acronym: terq >> Area: Real-time Applications and Infrastructure >> Area Director: TBD >> Chair(s): TBD >> Mailing address: TBD (currently dispatch@ietf.org) >>=20 >> Description of Working Group >>=20 >> Several IETF efforts have studied the handling of telephone numbers on t= he Internet. For example, the ENUM working group specified a DNS-based appr= oach to transforming telephone numbers into URIs; the DRINKS working group = produced a provisioning system suitable for populating Internet directories= of telephone numbers. The overall goal of this work has been to migrate th= e routing and directory functions of the telephone network onto the Interne= t, in order to simplify the implementation of Internet telephony and reduce= the Internet's reliance on the infrastructure of the public switched telep= hone network. Ultimately, the requirements for this project diverged signif= icantly from the original architecture and applicability of ENUM. Moreover,= in the twelve years since ENUM was first chartered, Internet telephony has= changed a great deal. As one example, today web-based applications are bec= oming more significant to Internet telephony, as are intelligent mobile dev= ices. In these e > nv >> ironments, there exists a capacity for richer queries and responses, as = well as more sophisticated application logic to process requests, but also = tougher security requirements. As such, this working group reconsiders the = migration of routing and directory functions from the telephone network to = the Internet by generalizing the base semantics of queries and responses in= an abstract framework, and then defining possible transports and encodings= for these messages. >>=20 >> The components of the chartered work include: >>=20 >> 1. A framework and information model for the construction queries and re= sponses. The information model will provide an abstract description of the = semantics of the various elements and attributes that make up TeRQ messages= . The framework will further establish the semantics of TeRQ transactions, = describe how responses are matched with queries, and give an overview of th= e operation of the protocol. It will furthermore describe the overall secur= ity model of TeRQ, including confidentiality and access control measures ne= cessary to preserve privacy. >>=20 >> 2. A process for specifying bindings for the information model, which co= mprise transports and encodings. Transports specify the underlying protocol= s that will encapsulate TeRQ queries and responses. This working group is n= ot chartered to define new underlying protocols, but will specify how the t= ransaction model of TeRQ maps onto these underlying protocols. Potential un= derlying protocols include HTTP and DIAMETER. The encoding determines how T= eRQ elements and attributes will be rendered in the object format carried b= y the transport; potential object formats would include JSON and XML and we= ll as lower-layer encodings. Binding specifications must detail their imple= mentation of the security and privacy requirements defined in the framework= . >>=20 >> 3. A set of one or more bindings compliant with the process described in= (2), which provide a concrete instantiation of the protocol. This group wi= ll be initially chartered to create a single binding, though other may be a= potential subject for ongoing work after a rechart. These bindings may acc= ompany profiles that detail particular sets of attributes or elements relev= ant to a given deployment. >>=20 >> The TeRQ working group will coordinate with ongoing work in the DRINKS s= pace in order to make sure that the TeRQ information model conforms with th= e needs of provisioning systems. Whenever possible, TeRQ will reuse existin= g IETF work. The syntax and semantics of telephone numbers, for example, ha= ve been the subject of a great deal of previous IETF work (notably RFC 3966= ), and the TeRQ working group will rely on this and related prior work.=20 >>=20 >> Goals and Deliverables: >>=20 >> Aug 2013 Submit Framework for Telephony Related Queries as Proposed S= tandard >> Nov 2013 Submit one TeRQ Binding as Proposed Standard >> Feb 2013 Recharter if additional bindings are required >> _______________________________________________ >> 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 >=20 From pp3129@att.com Mon Mar 11 05:50:34 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80C321F8746 for ; Mon, 11 Mar 2013 05:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ZWDjGmV8-nRr for ; Mon, 11 Mar 2013 05:50:33 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2D33F21F85A4 for ; Mon, 11 Mar 2013 05:50:32 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 713dd315.0.101775.00-472.243291.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 11 Mar 2013 12:50:32 +0000 (UTC) X-MXL-Hash: 513dd31816ff3b31-3ff85aa257b15ebaf2a9364ae66a8fd150a250c3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2BCoVRw027085; Mon, 11 Mar 2013 08:50:31 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2BCoOlx027055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Mar 2013 08:50:26 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 11 Mar 2013 12:50:06 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Mon, 11 Mar 2013 08:50:06 -0400 From: "PFAUTZ, PENN L" To: "Peterson, Jon" , "dispatch@ietf.org" Thread-Topic: terq charter revision Thread-Index: AQHOG4uwJd1j/+51NEWjvHcnnYJWfpigcQcg Date: Mon, 11 Mar 2013 12:50:05 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D61D3572@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <55A5A9A87506CB4BA580BF9D531957DA921A0424@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA921A0424@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=ZLJgbwHb c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=7rbOGru5kh8A:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=NGV5Wi1au] X-AnalysisOut: [AUA:10 a=48vgC7mUAAAA:8 a=UuePjYvMySSGnjmOmAcA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=iE9YWIBck50A:10 a=lZB815dzVvQA:10 a=mKrbKQqYGUu] X-AnalysisOut: [LMqfQ:21 a=LxXKh45XW9FQoU-A:21] Subject: Re: [dispatch] terq charter revision X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 12:50:34 -0000 Jon: I still have some questions about this enterprise: 1. What will be the basis for the information model to be developed? Will i= t address the needs of the service providers and regulators that currently = control the E.164 space or is it end user/webRTC focused? Or both? 2. What was attractive about ENUM was the way in which it leveraged an exis= ting protocol and ecosystem to make telephone numbers fit into IP. I'm not = quite sure how to think of the current effort in those terms. 3. w/r/t to "richer queries and responses" and " more sophisticated applica= tion logic", the only thing that richer seems to mean is source-based. Do w= e really need a new framework for that? And people have already found ways = to apply more sophisticated application logic by putting an ENUM front end = on a relational database. 4. The statement about making sure the information model conforms to the ne= eds of the provisioning systems concerns me in that, if we're taking the tr= ouble to define an information model de novo, the dictates of the model oug= ht to take precedence over the provisioning system rather than be restricte= d by it. 5. If we're serious about defining an encompassing information model I thin= k a framework by August 2013 is way optimistic, unless there's something wa= iting in the wings. Penn Pfautz AT&T +1-732-420-4962 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Peterson, Jon Sent: Thursday, March 07, 2013 6:27 PM To: dispatch@ietf.org Subject: [dispatch] terq charter revision Based on the comments previously received, this is a slight revision to the= TeRQ charter. The fundamentals here though are pretty much unchanged: the = plan is to do the framework and information model document and one binding = document, rechartering if there is interest in doing any further binding do= cuments. Jon Peterson NeuStar, Inc. --- Title: Telephony-Related Queries Acronym: terq Area: Real-time Applications and Infrastructure Area Director: TBD Chair(s): TBD Mailing address: TBD (currently dispatch@ietf.org) Description of Working Group Several IETF efforts have studied the handling of telephone numbers on the = Internet. For example, the ENUM working group specified a DNS-based approac= h to transforming telephone numbers into URIs; the DRINKS working group pro= duced a provisioning system suitable for populating Internet directories of= telephone numbers. The overall goal of this work has been to migrate the r= outing and directory functions of the telephone network onto the Internet, = in order to simplify the implementation of Internet telephony and reduce th= e Internet's reliance on the infrastructure of the public switched telephon= e network. Ultimately, the requirements for this project diverged significa= ntly from the original architecture and applicability of ENUM. Moreover, in= the twelve years since ENUM was first chartered, Internet telephony has ch= anged a great deal. As one example, today web-based applications are becomi= ng more significant to Internet telephony, as are intelligent mobile device= s. In these env ironments, there exists a capacity for richer queries and responses, as we= ll as more sophisticated application logic to process requests, but also to= ugher security requirements. As such, this working group reconsiders the mi= gration of routing and directory functions from the telephone network to th= e Internet by generalizing the base semantics of queries and responses in a= n abstract framework, and then defining possible transports and encodings f= or these messages. The components of the chartered work include: 1. A framework and information model for the construction queries and respo= nses. The information model will provide an abstract description of the sem= antics of the various elements and attributes that make up TeRQ messages. T= he framework will further establish the semantics of TeRQ transactions, des= cribe how responses are matched with queries, and give an overview of the o= peration of the protocol. It will furthermore describe the overall security= model of TeRQ, including confidentiality and access control measures neces= sary to preserve privacy. 2. A process for specifying bindings for the information model, which compr= ise transports and encodings. Transports specify the underlying protocols t= hat will encapsulate TeRQ queries and responses. This working group is not = chartered to define new underlying protocols, but will specify how the tran= saction model of TeRQ maps onto these underlying protocols. Potential under= lying protocols include HTTP and DIAMETER. The encoding determines how TeRQ= elements and attributes will be rendered in the object format carried by t= he transport; potential object formats would include JSON and XML and well = as lower-layer encodings. Binding specifications must detail their implemen= tation of the security and privacy requirements defined in the framework. 3. A set of one or more bindings compliant with the process described in (2= ), which provide a concrete instantiation of the protocol. This group will = be initially chartered to create a single binding, though other may be a po= tential subject for ongoing work after a rechart. These bindings may accomp= any profiles that detail particular sets of attributes or elements relevant= to a given deployment. The TeRQ working group will coordinate with ongoing work in the DRINKS spac= e in order to make sure that the TeRQ information model conforms with the n= eeds of provisioning systems. Whenever possible, TeRQ will reuse existing I= ETF work. The syntax and semantics of telephone numbers, for example, have = been the subject of a great deal of previous IETF work (notably RFC 3966), = and the TeRQ working group will rely on this and related prior work. Goals and Deliverables: Aug 2013 Submit Framework for Telephony Related Queries as Proposed = Standard Nov 2013 Submit one TeRQ Binding as Proposed Standard Feb 2013 Recharter if additional bindings are required _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From adam@nostrum.com Mon Mar 11 06:39:13 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB0321F8464 for ; Mon, 11 Mar 2013 06:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 TOJoEODmt0Xg for ; Mon, 11 Mar 2013 06:39:13 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7D521F8463 for ; Mon, 11 Mar 2013 06:39:13 -0700 (PDT) Received: from dhcp-5033.meeting.ietf.org (dhcp-5033.meeting.ietf.org [130.129.80.51]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2BDcfaS095480 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 11 Mar 2013 08:38:42 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <513DDE61.7010605@nostrum.com> Date: Mon, 11 Mar 2013 09:38:41 -0400 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 130.129.80.51 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org, Cullen Jennings , stephane.cazeaux@orange.com Subject: Re: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 13:39:13 -0000 On 3/10/13 18:38, Iñaki Baz Castillo wrote: > 2013/3/10 Cullen Jennings : >> If an offer such s that got passed into a browser and it died, I would view that as a bug. Of course I don' expect it to implement BFCP but I expect the newer to correctly reject it. Actually, if there was any string you could pass in from JS to the browser that caused the browser to die, I would consider that a bug. > Probably it's a bug as you say. But my question is: will browser > vendors allow passing "strange" stuff into the SDP? Taking into > account the SDP format complexity and the issues already being > discussed rigth now in rtcweb WG about SDP usage, I don't expect that > such an exotic SDP will work. > All I think you'll see is that the browser -- just like any other endpoint that doesn't support BFCP -- would decline the BFCP media section. /a From stpeter@stpeter.im Mon Mar 11 06:51:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D907B21F8841 for ; Mon, 11 Mar 2013 06:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 w983+a9vQXeK for ; Mon, 11 Mar 2013 06:51:50 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0951B21F87D7 for ; Mon, 11 Mar 2013 06:51:50 -0700 (PDT) Received: from [130.129.84.195] (unknown [130.129.84.195]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 303A6406A8; Mon, 11 Mar 2013 08:00:19 -0600 (MDT) Message-ID: <513DE174.8000007@stpeter.im> Date: Mon, 11 Mar 2013 09:51:48 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Michael Lundberg References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-saintandre-sip-xmpp-presence-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 13:51:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/9/13 7:29 PM, Michael Lundberg wrote: > Peter, > > Thanks for resubmitting the SIP-XMPP presence I-D. I think this > and the other documents are important as there are a lot of > interworking issues today with XMPP and SIP/SIMPLE implementations, > and I think these documents can help reduce some of those > interworking challenges. > > In order to help ensure interworking between different > implementations, I think Sections 5.2 and 5.3 need to have some > stronger ‘MUST’ language instead of SHOULDs, MAYs, etc. This will > enforce proper and complete mappings between implementations that > conform to this document. Quite possibly. In general I think it might be good to have a discussion about how strong we want to make the recommendations in this suite of documents. > While I don’t think the document needs to enforce the use of the > element mapping discussed in 5.2, I think if > implementations are going to use the mapping, this document should > enforce the use of a specific namespace and describe the mapping of > values specified in RFC 6121 (i.e., away, dnd, chat, and > xa). One option, as I suggested in the I-D, is to use the 'jabber:client' namespace, for instance: away However, I have heard that different presence/IM systems have different interpretations of the "dnd" (do not disturb) state. So I think we might need to work that out. > This will at least allow a minimum set of standard mappings between > XMPP and SIP, which can be expanded on in future document(s). > Section 5.3 could then also discuss how this mapping can be > accomplished from SIP to XMPP if the SIP endpoints/devices support > this same namespace. One of the big interworking challenges with > today’s implementations is the use of different namespaces given > the extensibility of XML-based presence standards (e.g., PIDF, > RPID), which allows individuals to create their own namespace. > This flexibility is good for ingenuity, but problematic for > interworking between different implementations. I think > standardizing a basic set of common status information using a > specific namespace is needed, and this document is a good place to > do that. That seems helpful. > In my opinion, I do not think Section 6 should be part of this > base document. While I like the idea of encapsulating the SIP > information into the XMPP message, I think this content > should be a consideration for implementing ‘rich presence’. As > written, this method is only applicable for SIP to XMPP > translation, and if the focus of this document is just ‘basic’ > presence information interworking, the SIP to XMPP mapping in > Section 5.3 already describes a method for how this can be > accomplished. IMHO it would be fine to remove Section 6, unless someone really wants it to be in this spec. Thanks for the feedback! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRPeFzAAoJEOoGpJErxa2pm6sP/3C+XEW4gUcnwHuCT0sHfTYi YOSzqzK+HT0fHjXRYjRthGu3ZF7qfBv4ak+0oR9GuzxzL49aku9HUcTCN8ZX9132 i85Fh/UxFGi1kHTu0g+YF1cIHas4niy4EYtZ7IyHoQ1aV1t9M+yvXH+8laEkAJ7V oBiCFtLMPDd64pXc8pxA8RS5NWgYEoYX89xEOXIh7vApVozT4DcsOmm/DBH7wmxG 0T/3dBCo6OYtJz0oBYhP8SwyxEQfpz1+2QSUulEfbhUN7ZuBZGNdWLLkxOeQq1gZ aSLNb6BZkxp2mGrFu2TblTW+E8wz7GVzua41+JvyU9ipXTfkEoDJVTAZTx1tdPDX HruAIB4p7e3MRFLBzDzYzUqH0OXfjt7EYV93fr9k7GKpGn6/mjlkr6i23b5dz/19 kZCt4Z9xSOLTxy9t3h2evd6huZrXeqkbCyXW7fB2wGam3/366/TDiYb3MTWxougV CveADTd3O9BKGobTu1laKaep6+ZqsWIUoYaxw2TFL1edUUqGDNlaw1b3+H1mjwHz dEFYAjDPMk3qiS7u7nrdTOE3fP4HkMoJoSZjZ+2z3YDpc44X5m1h0YqU4uxOiNsq Kjai2O3311z5qrZqICkn2l+mJh31JXPt35Jb+F8V2ztAImSf50HMQJFIC1FkMFNG vKUYWw6m+bj++I8ue21l =t1Zx -----END PGP SIGNATURE----- From prvs=5782954ab3=aallen@blackberry.com Mon Mar 11 07:18:44 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756AE21F8AA1 for ; Mon, 11 Mar 2013 07:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 DSUkL0qLiwaz for ; Mon, 11 Mar 2013 07:18:43 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3C321F8A96 for ; Mon, 11 Mar 2013 07:18:42 -0700 (PDT) X-AuditID: 0a412830-b7ef86d00000339d-2d-513de7c1889b Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 5E.11.13213.2C7ED315; Mon, 11 Mar 2013 09:18:42 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 09:18:41 -0500 From: Andrew Allen To: "dispatch@ietf.org" Thread-Topic: Test - please ignore Thread-Index: Ac4eY1QAvUhmOclcSNibJSbAkQWIhQ== Date: Mon, 11 Mar 2013 14:18:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D262D4XMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsXC5Zyvq3vouW2gwZweQYulkxawOjB6LFny kymAMaqB0SYpsaQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScx Mze1SEkhM8VWyURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb7 61pYmFrqGirZ6SZ08mQ82HeNqeAJf8XRjbkNjJP4uhg5OSQETCSe/dzJCmGLSVy4t56ti5GL Q0igjUliy9qjLBDOZkaJuT8/gVWxCWhJ7D88nQnEFhHQlji6qosZxBYWkJX4+uggI0RcSeLO 78vsXYwcQLaeRO8yd5Awi4CqRNfBV+wgNq+Ah8TGtzvBWhmBFn8/tQZsJLOAuMStJ/OZIA4S kFiy5zwzhC0q8fLxP6hDFSWWnTjJBlGfL3Fj00RGiJmCEidnPmGZwCg0C8moWUjKZiEpg4jr SCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYBXMzig3MDJPzkvWKMnP18lJLNjGCIt9Rw2AH 4/v3FocYBTgYlXh4za7aBgqxJpYVV+YeYpTgYFYS4V25ySZQiDclsbIqtSg/vqg0J7X4EGMQ MFQmMktxJ+cDk1JeSbyxgQGRHCVxXpFA0UAhgXRgUspOTS1ILYIZysTBCbKUS0qkGJhaUosS S0sy4kEJML4YmAKlGhgrFuyv4Zm/aPWy/D8vdyWXv3nnek/brFPp24W9c0OVt8xftnPznLPb N3yRFu3uO/fykrRbu3/bc2O93Svnhb+Y9batS/Xent+bDu7Z+pjPY9XiKLYlHKsO+++fm2HO 9GlRiG3N758P7AqXyJyvtGa0qD9sNyPgdcs6kzl8LzeZimldZl3p19W1WYmlOCPRUIu5qDgR ADHmI99KAwAA Subject: [dispatch] Test - please ignore X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 14:18:44 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338D262D4XMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable --------------------------------------------------------------------- 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. --_000_BBF5DDFE515C3946BC18D733B20DAD2338D262D4XMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

 

---------------------------------------------------------------------
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. --_000_BBF5DDFE515C3946BC18D733B20DAD2338D262D4XMB104ADSrimnet_-- From ibc@aliax.net Mon Mar 11 07:28:02 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A7B21F8BC5 for ; Mon, 11 Mar 2013 07:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 I2sYPBVrtzj2 for ; Mon, 11 Mar 2013 07:28:00 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6CE21F8BB3 for ; Mon, 11 Mar 2013 07:28:00 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id s14so2264972qeb.25 for ; Mon, 11 Mar 2013 07:28:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=I8mhte3aZm6oErZVUtpZM0Dc26GpVAFY5iNMDta4qZ8=; b=OQDfp5FCjoCsmDzv7g9BkDGCygrzo0rP41Rdni1lVkOVpbEW0sbAJwS+GdcLsXvL+3 n/bvcoVLR/UlReT+swxXZ5cw1VxnXDsQPPhvBPH8grbJU/OJn0TkbDM6BiTFxlZSD+xu sGabw+MLRkEUVlxG9fpIUyiONe6G7sg/dNv9Ld/3cSuGwztz3UaOusnhWwd7QJ4kcsEn FBSP2xjPN5Cjujhl6vLKzoeEva61p8ZiDNWM5qGx39bg6Ht8jSLrXzZcCq+f2bP/4vXY 1h+S6O/geiarnIrIV/no9OH9/WRj5+4z4AjSdIH3EdH3fsbK+EmWuJaju/6LcEWDIgl+ vYeg== X-Received: by 10.224.180.212 with SMTP id bv20mr17236174qab.6.1363012076439; Mon, 11 Mar 2013 07:27:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.12.233 with HTTP; Mon, 11 Mar 2013 07:27:36 -0700 (PDT) In-Reply-To: <513DDE61.7010605@nostrum.com> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> <513DDE61.7010605@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 11 Mar 2013 15:27:36 +0100 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnl0yMOU8NBzAxTtDabLfuX4Rh+xEUwQK2Vx3BaOwo+b1E9lkE15m76M25z+T/tNANKZfQf Cc: dispatch@ietf.org, Cullen Jennings , stephane.cazeaux@orange.com Subject: Re: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 14:28:02 -0000 2013/3/11 Adam Roach : > All I think you'll see is that the browser -- just like any other endpoin= t > that doesn't support BFCP -- would decline the BFCP media section. Hopefully yes :) Then the problem is how the JS code *parses* and *mangles* the SDP to interact with the BFPC media section, which is hard to accomplish given the SDP format... but that's another subject :) PS: Anyhow I would like to insist that, if BFPC means a "binary protocol", then it will be really hard to implement it at JavaScript level. --=20 I=C3=B1aki Baz Castillo From sergio.garcia.murillo@gmail.com Mon Mar 11 07:33:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7C921F8C22 for ; Mon, 11 Mar 2013 07:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.339 X-Spam-Level: * X-Spam-Status: No, score=1.339 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, RCVD_IN_SORBS_DUL=0.877] 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 ifofmI-XYtvF for ; Mon, 11 Mar 2013 07:33:50 -0700 (PDT) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D1BED21F8BF0 for ; Mon, 11 Mar 2013 07:33:49 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id q10so1195996eaj.5 for ; Mon, 11 Mar 2013 07:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ICziWJmpVyaRmAhOsp5p4uRk1mhVwEjeRMKGWeIElq8=; b=eN2djeR8t76XizrR6EULODubKgmNiiuhF9vBZvW6e3bZoVigWeeKBurW9R2P6vXz1O x8Ofgj4Tr435rXerZ+WGwVEBGlyE4/w8CW8x5VPlwafDjY1v6Bmfacty9oISRNQ+GWqH 0XePwIldIAYXCf8WTXVIQwjn+CREQWUqkP29VrHQODruqWtnHt+zP3b4zziOjVlVLVKW UrN+UyL8Khn34O7ptsOa6QYy0hzZyrg/mz70G3Gt3jI6SMeSdqKXcPTCEVb7HCHZMlCX 7SM0x6U+/eXjyD9raJLwD6uksWrQTv0KYUlAsp0NzXc+9SjQk2M8RvTyf5phBBgeimCX JO6g== X-Received: by 10.14.202.71 with SMTP id c47mr36610999eeo.39.1363012428901; Mon, 11 Mar 2013 07:33:48 -0700 (PDT) Received: from [192.168.1.38] (102.red-80-29-108.adsl.static.ccgg.telefonica.net. [80.29.108.102]) by mx.google.com with ESMTPS id h5sm23913620eem.1.2013.03.11.07.33.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 07:33:47 -0700 (PDT) Message-ID: <513DEB4A.3070403@gmail.com> Date: Mon, 11 Mar 2013 15:33:46 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> <513DDE61.7010605@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 14:33:50 -0000 El 11/03/2013 15:27, Iñaki Baz Castillo escribió: > 2013/3/11 Adam Roach : >> All I think you'll see is that the browser -- just like any other endpoint >> that doesn't support BFCP -- would decline the BFCP media section. > Hopefully yes :) > > Then the problem is how the JS code *parses* and *mangles* the SDP to > interact with the BFPC media section, which is hard to accomplish > given the SDP format... but that's another subject :) > > PS: Anyhow I would like to insist that, if BFPC means a "binary > protocol", then it will be really hard to implement it at JavaScript > level. Fully agree. Whatever protocol it is used, either websocket or datachannel, we will need to create a json/xml representation of the bcfp messages to be able to easily use it on browsers. Best regards Sergio From jon.peterson@neustar.biz Mon Mar 11 07:43:56 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FA411E810C for ; Mon, 11 Mar 2013 07:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 0kBWQdh+e1KT for ; Mon, 11 Mar 2013 07:43:55 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id AE4C211E8102 for ; Mon, 11 Mar 2013 07:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1363012916; x=1678340001; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=dv2PkFvFAQFr3LqVoyt8F shG3nixvYVKSwtXxo2IvlU=; b=ANBMYOmtnqoAUkXyepq/7awR4rrKBwbSTqfxk oFhLJGF8p2O13LywLoD6o/YcTYdNGc0LramtTNp6wVFAoojBA== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.17300042; Mon, 11 Mar 2013 10:41:55 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 11 Mar 2013 10:43:44 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.87]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 10:43:39 -0400 From: "Peterson, Jon" To: "'PFAUTZ, PENN L'" , "'dispatch@ietf.org'" Thread-Topic: terq charter revision Thread-Index: AQHOG4uwJd1j/+51NEWjvHcnnYJWfpigcQcggAAlg/s= Date: Mon, 11 Mar 2013 14:43:38 +0000 Message-ID: <596979554D802045BBD45C051A4399E4025E7B@stntexmb12.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.15.96] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: mr8dWN6y2YpA0i+9wCBHoA== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dispatch] terq charter revision X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 14:43:56 -0000 VGhhbmtzIGZvciB0aGVzZSBub3RlcyAtIHRvIHlvdXIgcG9pbnRzIGJlbG93OgoKMS4gVGVSUSBz ZXJ2ZXMgdGhlIHVzZSBjYXNlcyBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50LiBJdCBjYW4gaW5k ZWVkIGhlbHAgdG9kYXkncyBjYXJyaWVycywgYnV0IGl0IGNlcnRhaW5seSBpcyBub3QgbGltaXRl ZCB0byB0aGF0IHVzZSBjYXNlLiBJdCBpcyBiYXNlZCBvbiB0aGUgaWRlYSB0aGF0IEF1dGhvcml0 aWVzIGNhbiBwcm92aXNpb24gZGF0YSwgYnV0IHRoYXQgQXV0aG9yaXRpZXMgY2FuIGJlIGFueSBl bnRpdGllcyB0cnVzdGVkIGJ5IFNvdXJjZXMuIE9uZSBvZiB0aGUgbGltaXRhdGlvbnMgb2YgdGhl IEVOVU0gbW9kZWwgaGlzdG9yaWNhbGx5IHdhcyBpdHMgbW9ub2xpdGhpYyBpbml0aWFsIHRydXN0 IG1vZGVsIHJvb3RlZCBpbiBlMTY0LmFycGEsIHdoaWNoIHR1cm5lZCBvdXQgdG8gbWFwIHBvb3Js eSB0byB0aGUgcmVhbGl0aWVzIG9mIG51bWJlciBtYW5hZ2VtZW50LiBUaGF0IGxlZ2FjeSBlbmRl ZCB1cCBpbnNwaXJpbmcgbWFueSBrbHVkZ2VzIHRvIGdldCBFTlVNIHdvcmtpbmcgaW4gYW55IHBy YWN0aWNhbCBlbnZpcm9ubWVudC4gVGVSUSBpcyB0cnlpbmcgdG8gaW1wcm92ZSBvbiB0aGF0LgoK Mi4gSSdkIHNheSB0aGUgc2l0dWF0aW9uIGlzIG5vIGRpZmZlcmVudCBmb3IgVGVSUS4gRU5VTSBi dWlsdCBvbiB0aGUgRE5TLCBpdCdzIHRydWUsIGJ1dCB5b3Ugd291bGQgaGF2ZSBoYWQgYSBoYXJk IHRpbWUgZmluZGluZyBhIE5BUFRSIHBhcnNlciB3aGVuIEVOVU0gY2FtZSBvdXQsIGxldCBhbG9u ZSBvbmUgdGhhdCB1bmRlcnN0b29kIEVOVU1zIGludGVycHJldGF0aW9uIG9mIG9yZGVyIGFuZCBw cmVmZXJlbmNlLCBmb3IgZXhhbXBsZS4gVGVSUSBpcyBub3Qgb3V0IHRvIGJ1aWxkIGFueSBuZXcg cHJvdG9jb2xzLCBhbmQgd2hldGhlciBpdCBnZXRzIGJvdW5kIHRvIEhUVFAgb3IgRElBTUVURVIg b3Igd2hhdCBoYXZlIHlvdSwgdGhlIGFtb3VudCBvZiBuZXcgd29yayB5b3UnbGwgbmVlZCB0byBk byB0byBwYXJzZSB0aGUgb2JqZWN0cyBpdCBlbmNvZGVzIHdvbid0IGNvbXBhcmUgdG9vIHVuZmF2 b3JhYmx5IHRvIHRoZSBFTlVNIHByZWNlZGVudC4gCgozLiBUaGUgc2VjdXJpdHkgbW9kZWwgaXMg Y2VydGFpbmx5IHRoZSBtYWluIHdheSB0aGF0IFRlUlEgaXMgcmljaGVyLCBidXQgdGhhdCdzIG5v dCBqdXN0IGEgbWF0dGVyIG9mIHNvdXJjZSBpZGVudGlmaWNhdGlvbi4gSXQncyBhbHNvIGFib3V0 IEF1dGhvcml0aWVzLCBhbmQgcG90ZW50aWFsbHkgbXVsdGlwbGUgQXV0aG9yaXRpZXMsIGFzIEkg bm90ZWQuIEJ1dCB0aGUgZnVsbCBvbiBpbnZlbnRvcnkgc2VhcmNoIGJ5IGNhcGFiaWxpdHksIHRo ZSBhYmlsaXR5IHRvIG9wZXJhdGUgb24gbnVtYmVyIHJhbmdlcywgdG8gbmFycm93IHNlYXJjaGVz IHRocm91Z2ggYXR0cmlidXRlcywgYWxsIG9mIHRoZXNlIGFyZSB3aGF0IEkgbWFuIGJ5IHJpY2hu ZXNzLiBUaGV5IGFyZSBkZXNjcmliZWQgaW4gdGhlIHVzZSBjYXNlcy4KCjQuIFRoZSBjaGFydGVy IHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IHdlIGRvbid0IG5lZ2xlY3QgdGhlIHdvcmsgZG9uZSBp biBEUklOS1MgYW5kIGVsc2V3aGVyZSBpbiB0aGUgaUVURi4gSSBkb24ndCB0aGluayBUZVJRIHNo b3VsZCBiZSByZXN0cmljdGVkIHRvIHRoYXQgc2V0IG9mIHByb3Zpc2lvbmVkIGRhdGEsIGJ1dCBp dCBzaG91bGQgYmUgYWJsZSB0byBxdWVyeSBmb3IgdGhlIGRhdGEgdGhhdCBEUklOS1MgZGV0ZXJt aW5lZCBob3cgdG8gcHJvdmlzaW9uLiBJdCBpcyBhIGJpdCBvZiBxdWVzdGlvbiB3aGV0aGVyIEVO VU0gY2FuIGRvIHRoYXQsIGZvciBleGFtcGxlLCBiZWNhdXNlIHRoZSBMVUYvTFJGIGRpc3RpbmN0 aW9uIGltcGxpZXMgYW4gYWJpbGl0eSB0byBtYXAgU1BJRHMgdG8gVVJJcywgd2hlcmUgRU5VTSBp cyBleHBsaWNpdGx5IHNjb3BlZCB0byBtYXBwaW5nIGZyb20ganVzdCB0ZWxlcGhvbmUgbnVtYmVy cy4gVGhlIGFiaWxpdHkgdG8gdHJhbnNsYXRlIGlkZW50aWZpZXJzIGxpa2UgU1BJRHMgaXMsIGlu Y2lkZW50YWxseSwgYW5vdGhlciByZXNwZWN0IGluIHdoaWNoIHRoZSBUZVJRIG1vZGVsIGV4aGli aXRzIHJpY2huZXNzLgoKNS4gSXQncyBoYXJkIGZvciBtZSB0byBkZWZlbmQgYW55IGNoYXJ0ZXIg ZGF0ZXMgd2UgcHJvcG9zZSBpbiB0aGUgSUVURiB3aXRoIGEgc3RyYWlnaHQgZmFjZSwgYnV0IEkg dGhpbmsgdGhlIGluZm9ybWF0aW9uIG1vZGVsIGNvdWxkIGJlIGluIHdvcnNlIHNoYXBlLiBUaGUg bWFpbiB0aGluZyBpdCBuZWVkcyBub3cgaXMgdGhlIElBTkEgd29yayB0byBmaWxsIGluIGhvdyB5 b3UgZXh0ZW5kIGVsZW1lbnRzIGFuZCB0aGUgZXhhY3QgcHJvY2VzcyBmb3Igc3BlY2lmeWluZyBh IGJpbmRpbmcuIFdlJ3JlIG5vdCBnb2luZyB0byBkZWZpbmUgZXZlcnkgcG9zc2libGUgZWxlbWVu dCBvciBhdHRyaWJ1dGUgaW4gdGhlIGJhc2UgaW5mb3JtYXRpb24gbW9kZWwuIElmIHdlIGNhbiBn ZXQgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGRvd24sIEkgZG9uJ3QgdGhpbmsgdGhlcmUncyBh IHRvbiBtb3JlIHRvIGRvIG9uIHRoaXMgZG9jdW1lbnQuIAoKSG9wZSB0aGF0IGhlbHBzLAoKSm9u IFBldGVyc29uCk5ldVN0YXIsIEluYy4KCg0NU2VudCB3aXRoIEdvb2QgKHd3dy5nb29kLmNvbSkK DQoNCiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogCVBGQVVUWiwgUEVOTiBMIFtt YWlsdG86cHAzMTI5QGF0dC5jb21dDQpTZW50OglNb25kYXksIE1hcmNoIDExLCAyMDEzIDA4OjUw IEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86CVBldGVyc29uLCBKb247IGRpc3BhdGNoQGll dGYub3JnDQpTdWJqZWN0OglSRTogdGVycSBjaGFydGVyIHJldmlzaW9uDQoNCkpvbjoNCkkgc3Rp bGwgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGlzIGVudGVycHJpc2U6DQoxLiBXaGF0IHdp bGwgYmUgdGhlIGJhc2lzIGZvciB0aGUgaW5mb3JtYXRpb24gbW9kZWwgdG8gYmUgZGV2ZWxvcGVk PyBXaWxsIGl0IGFkZHJlc3MgdGhlIG5lZWRzIG9mIHRoZSBzZXJ2aWNlIHByb3ZpZGVycyBhbmQg cmVndWxhdG9ycyB0aGF0IGN1cnJlbnRseSBjb250cm9sIHRoZSBFLjE2NCBzcGFjZSBvciBpcyBp dCBlbmQgdXNlci93ZWJSVEMgZm9jdXNlZD8gT3IgYm90aD8NCjIuIFdoYXQgd2FzIGF0dHJhY3Rp dmUgYWJvdXQgRU5VTSB3YXMgdGhlIHdheSBpbiB3aGljaCBpdCBsZXZlcmFnZWQgYW4gZXhpc3Rp bmcgcHJvdG9jb2wgYW5kIGVjb3N5c3RlbSB0byBtYWtlIHRlbGVwaG9uZSBudW1iZXJzIGZpdCBp bnRvIElQLiBJJ20gbm90IHF1aXRlIHN1cmUgaG93IHRvIHRoaW5rIG9mIHRoZSBjdXJyZW50IGVm Zm9ydCBpbiB0aG9zZSB0ZXJtcy4NCjMuIHcvci90IHRvICJyaWNoZXIgcXVlcmllcyBhbmQgcmVz cG9uc2VzIiBhbmQgIiBtb3JlIHNvcGhpc3RpY2F0ZWQgYXBwbGljYXRpb24gbG9naWMiLCB0aGUg b25seSB0aGluZyB0aGF0IHJpY2hlciBzZWVtcyB0byBtZWFuIGlzIHNvdXJjZS1iYXNlZC4gRG8g d2UgcmVhbGx5IG5lZWQgYSBuZXcgZnJhbWV3b3JrIGZvciB0aGF0PyBBbmQgcGVvcGxlIGhhdmUg YWxyZWFkeSBmb3VuZCB3YXlzIHRvIGFwcGx5IG1vcmUgc29waGlzdGljYXRlZCBhcHBsaWNhdGlv biBsb2dpYyBieSBwdXR0aW5nIGFuIEVOVU0gZnJvbnQgZW5kIG9uIGEgcmVsYXRpb25hbCBkYXRh YmFzZS4NCjQuIFRoZSBzdGF0ZW1lbnQgYWJvdXQgbWFraW5nIHN1cmUgdGhlIGluZm9ybWF0aW9u IG1vZGVsIGNvbmZvcm1zIHRvIHRoZSBuZWVkcyBvZiB0aGUgcHJvdmlzaW9uaW5nIHN5c3RlbXMg Y29uY2VybnMgbWUgaW4gdGhhdCwgaWYgd2UncmUgdGFraW5nIHRoZSB0cm91YmxlIHRvIGRlZmlu ZSBhbiBpbmZvcm1hdGlvbiBtb2RlbCBkZSBub3ZvLCB0aGUgZGljdGF0ZXMgb2YgdGhlIG1vZGVs IG91Z2h0IHRvIHRha2UgcHJlY2VkZW5jZSBvdmVyIHRoZSBwcm92aXNpb25pbmcgc3lzdGVtIHJh dGhlciB0aGFuIGJlIHJlc3RyaWN0ZWQgYnkgaXQuDQo1LiBJZiB3ZSdyZSBzZXJpb3VzIGFib3V0 IGRlZmluaW5nIGFuIGVuY29tcGFzc2luZyBpbmZvcm1hdGlvbiBtb2RlbCBJIHRoaW5rIGEgZnJh bWV3b3JrIGJ5IEF1Z3VzdCAyMDEzIGlzIHdheSBvcHRpbWlzdGljLCB1bmxlc3MgdGhlcmUncyBz b21ldGhpbmcgd2FpdGluZyBpbiB0aGUgd2luZ3MuDQoNCg0KDQoNClBlbm4gUGZhdXR6DQpBVCZU DQorMS03MzItNDIwLTQ5NjINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRp c3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgUGV0ZXJzb24sIEpvbg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDA3LCAy MDEzIDY6MjcgUE0NClRvOiBkaXNwYXRjaEBpZXRmLm9yZw0KU3ViamVjdDogW2Rpc3BhdGNoXSB0 ZXJxIGNoYXJ0ZXIgcmV2aXNpb24NCg0KDQpCYXNlZCBvbiB0aGUgY29tbWVudHMgcHJldmlvdXNs eSByZWNlaXZlZCwgdGhpcyBpcyBhIHNsaWdodCByZXZpc2lvbiB0byB0aGUgVGVSUSBjaGFydGVy LiBUaGUgZnVuZGFtZW50YWxzIGhlcmUgdGhvdWdoIGFyZSBwcmV0dHkgbXVjaCB1bmNoYW5nZWQ6 IHRoZSBwbGFuIGlzIHRvIGRvIHRoZSBmcmFtZXdvcmsgYW5kIGluZm9ybWF0aW9uIG1vZGVsIGRv Y3VtZW50IGFuZCBvbmUgYmluZGluZyBkb2N1bWVudCwgcmVjaGFydGVyaW5nIGlmIHRoZXJlIGlz IGludGVyZXN0IGluIGRvaW5nIGFueSBmdXJ0aGVyIGJpbmRpbmcgZG9jdW1lbnRzLg0KDQpKb24g UGV0ZXJzb24NCk5ldVN0YXIsIEluYy4NCg0KLS0tDQoNClRpdGxlOiBUZWxlcGhvbnktUmVsYXRl ZCBRdWVyaWVzDQpBY3JvbnltOiB0ZXJxDQpBcmVhOiBSZWFsLXRpbWUgQXBwbGljYXRpb25zIGFu ZCBJbmZyYXN0cnVjdHVyZQ0KQXJlYSBEaXJlY3RvcjogVEJEDQpDaGFpcihzKTogVEJEDQpNYWls aW5nIGFkZHJlc3M6IFRCRCAoY3VycmVudGx5IGRpc3BhdGNoQGlldGYub3JnKQ0KDQpEZXNjcmlw dGlvbiBvZiBXb3JraW5nIEdyb3VwDQoNClNldmVyYWwgSUVURiBlZmZvcnRzIGhhdmUgc3R1ZGll ZCB0aGUgaGFuZGxpbmcgb2YgdGVsZXBob25lIG51bWJlcnMgb24gdGhlIEludGVybmV0LiBGb3Ig ZXhhbXBsZSwgdGhlIEVOVU0gd29ya2luZyBncm91cCBzcGVjaWZpZWQgYSBETlMtYmFzZWQgYXBw cm9hY2ggdG8gdHJhbnNmb3JtaW5nIHRlbGVwaG9uZSBudW1iZXJzIGludG8gVVJJczsgdGhlIERS SU5LUyB3b3JraW5nIGdyb3VwIHByb2R1Y2VkIGEgcHJvdmlzaW9uaW5nIHN5c3RlbSBzdWl0YWJs ZSBmb3IgcG9wdWxhdGluZyBJbnRlcm5ldCBkaXJlY3RvcmllcyBvZiB0ZWxlcGhvbmUgbnVtYmVy cy4gVGhlIG92ZXJhbGwgZ29hbCBvZiB0aGlzIHdvcmsgaGFzIGJlZW4gdG8gbWlncmF0ZSB0aGUg cm91dGluZyBhbmQgZGlyZWN0b3J5IGZ1bmN0aW9ucyBvZiB0aGUgdGVsZXBob25lIG5ldHdvcmsg b250byB0aGUgSW50ZXJuZXQsIGluIG9yZGVyIHRvIHNpbXBsaWZ5IHRoZSBpbXBsZW1lbnRhdGlv biBvZiBJbnRlcm5ldCB0ZWxlcGhvbnkgYW5kIHJlZHVjZSB0aGUgSW50ZXJuZXQncyByZWxpYW5j ZSBvbiB0aGUgaW5mcmFzdHJ1Y3R1cmUgb2YgdGhlIHB1YmxpYyBzd2l0Y2hlZCB0ZWxlcGhvbmUg bmV0d29yay4gVWx0aW1hdGVseSwgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhpcyBwcm9qZWN0IGRp dmVyZ2VkIHNpZ25pZmljYW50bHkgZnJvbSB0aGUgb3JpZ2luYWwgYXJjaGl0ZWN0dXJlIGFuZCBh cHBsaWNhYmlsaXR5IG9mIEVOVU0uIE1vcmVvdmVyLCBpbiB0aGUgdHdlbHZlIHllYXJzIHNpbmNl IEVOVU0gd2FzIGZpcnN0IGNoYXJ0ZXJlZCwgSW50ZXJuZXQgdGVsZXBob255IGhhcyBjaGFuZ2Vk IGEgZ3JlYXQgZGVhbC4gQXMgb25lIGV4YW1wbGUsIHRvZGF5IHdlYi1iYXNlZCBhcHBsaWNhdGlv bnMgYXJlIGJlY29taW5nIG1vcmUgc2lnbmlmaWNhbnQgdG8gSW50ZXJuZXQgdGVsZXBob255LCBh cyBhcmUgaW50ZWxsaWdlbnQgbW9iaWxlIGRldmljZXMuIEluIHRoZXNlIGVudg0KIGlyb25tZW50 cywgdGhlcmUgZXhpc3RzIGEgY2FwYWNpdHkgZm9yIHJpY2hlciBxdWVyaWVzIGFuZCByZXNwb25z ZXMsIGFzIHdlbGwgYXMgbW9yZSBzb3BoaXN0aWNhdGVkIGFwcGxpY2F0aW9uIGxvZ2ljIHRvIHBy b2Nlc3MgcmVxdWVzdHMsIGJ1dCBhbHNvIHRvdWdoZXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLiBB cyBzdWNoLCB0aGlzIHdvcmtpbmcgZ3JvdXAgcmVjb25zaWRlcnMgdGhlIG1pZ3JhdGlvbiBvZiBy b3V0aW5nIGFuZCBkaXJlY3RvcnkgZnVuY3Rpb25zIGZyb20gdGhlIHRlbGVwaG9uZSBuZXR3b3Jr IHRvIHRoZSBJbnRlcm5ldCBieSBnZW5lcmFsaXppbmcgdGhlIGJhc2Ugc2VtYW50aWNzIG9mIHF1 ZXJpZXMgYW5kIHJlc3BvbnNlcyBpbiBhbiBhYnN0cmFjdCBmcmFtZXdvcmssIGFuZCB0aGVuIGRl ZmluaW5nIHBvc3NpYmxlIHRyYW5zcG9ydHMgYW5kIGVuY29kaW5ncyBmb3IgdGhlc2UgbWVzc2Fn ZXMuDQoNClRoZSBjb21wb25lbnRzIG9mIHRoZSBjaGFydGVyZWQgd29yayBpbmNsdWRlOg0KDQox LiBBIGZyYW1ld29yayBhbmQgaW5mb3JtYXRpb24gbW9kZWwgZm9yIHRoZSBjb25zdHJ1Y3Rpb24g cXVlcmllcyBhbmQgcmVzcG9uc2VzLiBUaGUgaW5mb3JtYXRpb24gbW9kZWwgd2lsbCBwcm92aWRl IGFuIGFic3RyYWN0IGRlc2NyaXB0aW9uIG9mIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHZhcmlvdXMg ZWxlbWVudHMgYW5kIGF0dHJpYnV0ZXMgdGhhdCBtYWtlIHVwIFRlUlEgbWVzc2FnZXMuIFRoZSBm cmFtZXdvcmsgd2lsbCBmdXJ0aGVyIGVzdGFibGlzaCB0aGUgc2VtYW50aWNzIG9mIFRlUlEgdHJh bnNhY3Rpb25zLCBkZXNjcmliZSBob3cgcmVzcG9uc2VzIGFyZSBtYXRjaGVkIHdpdGggcXVlcmll cywgYW5kIGdpdmUgYW4gb3ZlcnZpZXcgb2YgdGhlIG9wZXJhdGlvbiBvZiB0aGUgcHJvdG9jb2wu IEl0IHdpbGwgZnVydGhlcm1vcmUgZGVzY3JpYmUgdGhlIG92ZXJhbGwgc2VjdXJpdHkgbW9kZWwg b2YgVGVSUSwgaW5jbHVkaW5nIGNvbmZpZGVudGlhbGl0eSBhbmQgYWNjZXNzIGNvbnRyb2wgbWVh c3VyZXMgbmVjZXNzYXJ5IHRvIHByZXNlcnZlIHByaXZhY3kuDQoNCjIuIEEgcHJvY2VzcyBmb3Ig c3BlY2lmeWluZyBiaW5kaW5ncyBmb3IgdGhlIGluZm9ybWF0aW9uIG1vZGVsLCB3aGljaCBjb21w cmlzZSB0cmFuc3BvcnRzIGFuZCBlbmNvZGluZ3MuIFRyYW5zcG9ydHMgc3BlY2lmeSB0aGUgdW5k ZXJseWluZyBwcm90b2NvbHMgdGhhdCB3aWxsIGVuY2Fwc3VsYXRlIFRlUlEgcXVlcmllcyBhbmQg cmVzcG9uc2VzLiBUaGlzIHdvcmtpbmcgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZWZpbmUg bmV3IHVuZGVybHlpbmcgcHJvdG9jb2xzLCBidXQgd2lsbCBzcGVjaWZ5IGhvdyB0aGUgdHJhbnNh Y3Rpb24gbW9kZWwgb2YgVGVSUSBtYXBzIG9udG8gdGhlc2UgdW5kZXJseWluZyBwcm90b2NvbHMu IFBvdGVudGlhbCB1bmRlcmx5aW5nIHByb3RvY29scyBpbmNsdWRlIEhUVFAgYW5kIERJQU1FVEVS LiBUaGUgZW5jb2RpbmcgZGV0ZXJtaW5lcyBob3cgVGVSUSBlbGVtZW50cyBhbmQgYXR0cmlidXRl cyB3aWxsIGJlIHJlbmRlcmVkIGluIHRoZSBvYmplY3QgZm9ybWF0IGNhcnJpZWQgYnkgdGhlIHRy YW5zcG9ydDsgcG90ZW50aWFsIG9iamVjdCBmb3JtYXRzIHdvdWxkIGluY2x1ZGUgSlNPTiBhbmQg WE1MIGFuZCB3ZWxsIGFzIGxvd2VyLWxheWVyIGVuY29kaW5ncy4gQmluZGluZyBzcGVjaWZpY2F0 aW9ucyBtdXN0IGRldGFpbCB0aGVpciBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc2VjdXJpdHkgYW5k IHByaXZhY3kgcmVxdWlyZW1lbnRzIGRlZmluZWQgaW4gdGhlIGZyYW1ld29yay4NCg0KMy4gQSBz ZXQgb2Ygb25lIG9yIG1vcmUgYmluZGluZ3MgY29tcGxpYW50IHdpdGggdGhlIHByb2Nlc3MgZGVz Y3JpYmVkIGluICgyKSwgd2hpY2ggcHJvdmlkZSBhIGNvbmNyZXRlIGluc3RhbnRpYXRpb24gb2Yg dGhlIHByb3RvY29sLiBUaGlzIGdyb3VwIHdpbGwgYmUgaW5pdGlhbGx5IGNoYXJ0ZXJlZCB0byBj cmVhdGUgYSBzaW5nbGUgYmluZGluZywgdGhvdWdoIG90aGVyIG1heSBiZSBhIHBvdGVudGlhbCBz dWJqZWN0IGZvciBvbmdvaW5nIHdvcmsgYWZ0ZXIgYSByZWNoYXJ0LiBUaGVzZSBiaW5kaW5ncyBt YXkgYWNjb21wYW55IHByb2ZpbGVzIHRoYXQgZGV0YWlsIHBhcnRpY3VsYXIgc2V0cyBvZiBhdHRy aWJ1dGVzIG9yIGVsZW1lbnRzIHJlbGV2YW50IHRvIGEgZ2l2ZW4gZGVwbG95bWVudC4NCg0KVGhl IFRlUlEgd29ya2luZyBncm91cCB3aWxsIGNvb3JkaW5hdGUgd2l0aCBvbmdvaW5nIHdvcmsgaW4g dGhlIERSSU5LUyBzcGFjZSBpbiBvcmRlciB0byBtYWtlIHN1cmUgdGhhdCB0aGUgVGVSUSBpbmZv cm1hdGlvbiBtb2RlbCBjb25mb3JtcyB3aXRoIHRoZSBuZWVkcyBvZiBwcm92aXNpb25pbmcgc3lz dGVtcy4gV2hlbmV2ZXIgcG9zc2libGUsIFRlUlEgd2lsbCByZXVzZSBleGlzdGluZyBJRVRGIHdv cmsuIFRoZSBzeW50YXggYW5kIHNlbWFudGljcyBvZiB0ZWxlcGhvbmUgbnVtYmVycywgZm9yIGV4 YW1wbGUsIGhhdmUgYmVlbiB0aGUgc3ViamVjdCBvZiBhIGdyZWF0IGRlYWwgb2YgcHJldmlvdXMg SUVURiB3b3JrIChub3RhYmx5IFJGQyAzOTY2KSwgYW5kIHRoZSBUZVJRIHdvcmtpbmcgZ3JvdXAg d2lsbCByZWx5IG9uIHRoaXMgYW5kIHJlbGF0ZWQgcHJpb3Igd29yay4NCg0KR29hbHMgYW5kIERl bGl2ZXJhYmxlczoNCg0KQXVnIDIwMTMgICAgICAgIFN1Ym1pdCBGcmFtZXdvcmsgZm9yIFRlbGVw aG9ueSBSZWxhdGVkIFF1ZXJpZXMgYXMgUHJvcG9zZWQgU3RhbmRhcmQNCk5vdiAyMDEzICAgICAg ICBTdWJtaXQgb25lIFRlUlEgQmluZGluZyBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KRmViIDIwMTMg ICAgICAgIFJlY2hhcnRlciBpZiBhZGRpdGlvbmFsIGJpbmRpbmdzIGFyZSByZXF1aXJlZA0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNoIG1h aWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGlzcGF0Y2gNCg== From prvs=4782610f02=aallen@blackberry.com Mon Mar 11 07:57:14 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E7F21F8C54 for ; Mon, 11 Mar 2013 07:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 JqYKkCA-eb06 for ; Mon, 11 Mar 2013 07:57:13 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 79DC321F8C4E for ; Mon, 11 Mar 2013 07:57:13 -0700 (PDT) X-AuditID: 0a412830-b7ef86d00000339d-1f-513df0bb0831 Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id CB.B2.13213.CB0FD315; Mon, 11 Mar 2013 09:57:00 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 09:56:59 -0500 From: Andrew Allen To: "dispatch@ietf.org" Thread-Topic: Test - please ignore Thread-Index: Ac4eY1QAvUhmOclcSNibJSbAkQWIhQABVLaQ Date: Mon, 11 Mar 2013 14:56:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D263E4XMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAKsWRmVeSWpSXmKPExsXC5Zyvrbvng22gwf4jShZLJy1gdWD0WLLk J1MAY1QDo01SYklZcGZ6nr6dTWJeXn5JYkmqQkpqcbKtkk9qemKOQkBRZllicqWCS2Zxck5i Zm5qkZJCZoqtkomSQkFOYnJqbmpeia1SYkFBal6Kkh2XAgawASrLzFNIzUvOT8nMS7dV8gz2 17WwMLXUNVSy003o5Mn4ffkQY8F38Yq7/7+wNzAuF+1i5OCQEDCRuLjdsouRE8gUk7hwbz1b FyMXh5BAG5PEvTsrGCGczYwSu55/ZwepYhPQkth/eDoTiC0ioC1xdFUXM4gtLKAosa29nREi riRx5/dldgjbSGLp2rlg9SwCqhLt286DxXkFPCTeHJzPCmILAdkLn+8Di3MKeErse/sWbCaj gKzE7rPXwXqZBcQlbj2ZzwRxqYDEkj3nmSFsUYmXj/+xQtiKEstOnGSDqM+X+L31MivELkGJ kzOfsExgFJmFZNQsJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYyCuRnFBmaG yXnJekWZuXp5qSWbGEGpwlHDYAfj+/cWhxgFOBiVeHiXvLINFGJNLCuuzD3EKMHBrCTCu3KT TaAQb0piZVVqUX58UWlOavEhxiBgaE1kluJOzgemsbySeGMDAyI5SuK8IoGigUIC6cA0lp2a WpBaBDOUiYMTZCmXlEgxMBmlFiWWlmTEg1JmfDEwaUo1MMo6V1zTS9ue7iAb/Wvf+neah83f hLS8f8c747mikonLTcv+r7MOrfh2f8OCVSzeGqHNbm6HbBmaf/FVb7hk+qCLZdbRw0DPSuos ncSnInB5VsC0uh/JOYeeRGXOlS+ZVXPpcYVOrh1zYsufzfkzcpbE6byctenHlvOvlKP5tdu0 HvdO7OcPVmIpzkg01GIuKk4EAHPL+9ZjAwAA Subject: Re: [dispatch] Test - please ignore X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 14:57:14 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338D263E4XMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Sorry for the additional spam From: Andrew Allen Sent: Monday, March 11, 2013 10:19 AM To: dispatch@ietf.org Subject: Test - please ignore --------------------------------------------------------------------- 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. --_000_BBF5DDFE515C3946BC18D733B20DAD2338D263E4XMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Sorry for the additiona= l spam

 

From: Andrew Alle= n
Sent: Monday, March 11, 2013 10:19 AM
To: dispatch@ietf.org
Subject: Test - please ignore

 

 

---------------------------------------------------------------------
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. --_000_BBF5DDFE515C3946BC18D733B20DAD2338D263E4XMB104ADSrimnet_-- From jon.peterson@neustar.biz Mon Mar 11 08:24:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0758A21F8A52 for ; Mon, 11 Mar 2013 08:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 1jNFizb5OH6Y for ; Mon, 11 Mar 2013 08:24:48 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9982321F8A3F for ; Mon, 11 Mar 2013 08:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1363015924; x=1678331601; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=tU1aSDdd8RgpK4VyU5AGw hM3MAa7LOMpsRz9Z+eJ+3U=; b=ZOdBpFet8M3Xqm9wbmEcO9p+Ltdwx4XYibRtW i+fVUXFm26EtmOuzhaaRaloUsHcXtbWt9yGPC4dcs/ayNimCA== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.21550020; Mon, 11 Mar 2013 11:32:03 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 11 Mar 2013 11:24:39 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.87]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 11 Mar 2013 11:24:36 -0400 From: "Peterson, Jon" To: 'Henning Schulzrinne' Thread-Topic: [dispatch] terq charter revision Thread-Index: AQHOG4uwJd1j/+51NEWjvHcnnYJWfpif2mkAgADHkug= Date: Mon, 11 Mar 2013 15:24:35 +0000 Message-ID: <596979554D802045BBD45C051A4399E4025F3B@stntexmb12.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.15.96] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: a+af1otbl6jvi95vaPB08g== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] terq charter revision X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 15:24:50 -0000 VGhlIHVzZSBjYXNlcyB0byBkYXRlIGFueXdheSBzY29wZSBUZVJRIHRvIGluZm9ybWF0aW9uIHJl dHJpZXZhbCwgbm90IHByb3Zpc2lvbmluZy4gV2UgY2FuIG1ha2UgdGhpcyBleHBsaWNpdCBpbiB0 aGUgY2hhcnRlciBpZiB0aGF0IHdvdWxkIGJlIGhlbHBmdWwuIAoKSSBoYXZlIGxvb2tlZCBhIGJp dCBhIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGlzIHdvcmsgYW5kIFdFSVJEUywgeWVzLiBU aGF0IHRvbyBpcyBzb21ldGhpbmcgd2UgY291bGQgY2FsbCBvdXQgaW4gdGhlIGNoYXJ0ZXIgYXMg YW5vdGhlciBwb3RlbnRpYWwgcG9pbnQgb2YgYXBwcm9wcmlhdGlvbiBvciBjb2xsYWJvcmF0aW9u LiAKCkpvbiBQZXRlcnNvbgpOZXVTdGFyLCBJbmMuCgoNDVNlbnQgd2l0aCBHb29kICh3d3cuZ29v ZC5jb20pCg0KDQogLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IAlIZW5uaW5nIFNj aHVsenJpbm5lIFttYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdV0NClNlbnQ6CVN1bmRheSwgTWFy Y2ggMTAsIDIwMTMgMTA6NDEgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzoJUGV0ZXJzb24s IEpvbg0KQ2M6CWRpc3BhdGNoQGlldGYub3JnDQpTdWJqZWN0OglSZTogW2Rpc3BhdGNoXSB0ZXJx IGNoYXJ0ZXIgcmV2aXNpb24NCg0KVHdvIHF1ZXN0aW9ucy9jb21tZW50czoNCg0KKDEpIEl0IGlz IG5vdCBxdWl0ZSBjbGVhciB3aGV0aGVyIHRoZSBzY29wZSBpcyByZXN0cmljdGVkIHRvIHJldHJp ZXZhbCAoIkdFVCIpIG9yIGFsc28gdXBkYXRlcyBieSBhdXRob3JpemVkIGVudGl0aWVzICgiUFVU IikuIEZvciBIVFRQLCBpdCBzZWVtcyByZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZCB0byBzcGVj aWZ5IGJvdGgsIGxlc3Mgc28gZm9yIERJQU1FVEVSLCBidXQgSSBkb24ndCBzZWUgbXVjaCBvZiBh IHByb2JsZW0gd2l0aCBoYXZpbmcgc2V2ZXJhbCByZXRyaWV2YWwgbWVjaGFuaXNtcy4NCg0KKDIp IFRoZXJlIGlzIHNvbWUgcmVsYXRpb25zaGlwIHRvIHRoZSB3aG9pcyByZXRyaWV2YWwgd29yaywg SSBiZWxpZXZlLiBUaGlzIHNob3VsZCBhdCBsZWFzdCBiZSBleHBsb3JlZC4NCg0KSGVubmluZw0K DQpPbiBNYXIgNywgMjAxMywgYXQgNjoyNyBQTSwgIlBldGVyc29uLCBKb24iIDxqb24ucGV0ZXJz b25AbmV1c3Rhci5iaXo+IHdyb3RlOg0KDQo+IA0KPiBCYXNlZCBvbiB0aGUgY29tbWVudHMgcHJl dmlvdXNseSByZWNlaXZlZCwgdGhpcyBpcyBhIHNsaWdodCByZXZpc2lvbiB0byB0aGUgVGVSUSBj aGFydGVyLiBUaGUgZnVuZGFtZW50YWxzIGhlcmUgdGhvdWdoIGFyZSBwcmV0dHkgbXVjaCB1bmNo YW5nZWQ6IHRoZSBwbGFuIGlzIHRvIGRvIHRoZSBmcmFtZXdvcmsgYW5kIGluZm9ybWF0aW9uIG1v ZGVsIGRvY3VtZW50IGFuZCBvbmUgYmluZGluZyBkb2N1bWVudCwgcmVjaGFydGVyaW5nIGlmIHRo ZXJlIGlzIGludGVyZXN0IGluIGRvaW5nIGFueSBmdXJ0aGVyIGJpbmRpbmcgZG9jdW1lbnRzLg0K PiANCj4gSm9uIFBldGVyc29uDQo+IE5ldVN0YXIsIEluYy4NCj4gDQo+IC0tLQ0KPiANCj4gVGl0 bGU6IFRlbGVwaG9ueS1SZWxhdGVkIFF1ZXJpZXMNCj4gQWNyb255bTogdGVycQ0KPiBBcmVhOiBS ZWFsLXRpbWUgQXBwbGljYXRpb25zIGFuZCBJbmZyYXN0cnVjdHVyZQ0KPiBBcmVhIERpcmVjdG9y OiBUQkQNCj4gQ2hhaXIocyk6IFRCRA0KPiBNYWlsaW5nIGFkZHJlc3M6IFRCRCAoY3VycmVudGx5 IGRpc3BhdGNoQGlldGYub3JnKQ0KPiANCj4gRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cA0K PiANCj4gU2V2ZXJhbCBJRVRGIGVmZm9ydHMgaGF2ZSBzdHVkaWVkIHRoZSBoYW5kbGluZyBvZiB0 ZWxlcGhvbmUgbnVtYmVycyBvbiB0aGUgSW50ZXJuZXQuIEZvciBleGFtcGxlLCB0aGUgRU5VTSB3 b3JraW5nIGdyb3VwIHNwZWNpZmllZCBhIEROUy1iYXNlZCBhcHByb2FjaCB0byB0cmFuc2Zvcm1p bmcgdGVsZXBob25lIG51bWJlcnMgaW50byBVUklzOyB0aGUgRFJJTktTIHdvcmtpbmcgZ3JvdXAg cHJvZHVjZWQgYSBwcm92aXNpb25pbmcgc3lzdGVtIHN1aXRhYmxlIGZvciBwb3B1bGF0aW5nIElu dGVybmV0IGRpcmVjdG9yaWVzIG9mIHRlbGVwaG9uZSBudW1iZXJzLiBUaGUgb3ZlcmFsbCBnb2Fs IG9mIHRoaXMgd29yayBoYXMgYmVlbiB0byBtaWdyYXRlIHRoZSByb3V0aW5nIGFuZCBkaXJlY3Rv cnkgZnVuY3Rpb25zIG9mIHRoZSB0ZWxlcGhvbmUgbmV0d29yayBvbnRvIHRoZSBJbnRlcm5ldCwg aW4gb3JkZXIgdG8gc2ltcGxpZnkgdGhlIGltcGxlbWVudGF0aW9uIG9mIEludGVybmV0IHRlbGVw aG9ueSBhbmQgcmVkdWNlIHRoZSBJbnRlcm5ldCdzIHJlbGlhbmNlIG9uIHRoZSBpbmZyYXN0cnVj dHVyZSBvZiB0aGUgcHVibGljIHN3aXRjaGVkIHRlbGVwaG9uZSBuZXR3b3JrLiBVbHRpbWF0ZWx5 LCB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGlzIHByb2plY3QgZGl2ZXJnZWQgc2lnbmlmaWNhbnRs eSBmcm9tIHRoZSBvcmlnaW5hbCBhcmNoaXRlY3R1cmUgYW5kIGFwcGxpY2FiaWxpdHkgb2YgRU5V TS4gTW9yZW92ZXIsIGluIHRoZSB0d2VsdmUgeWVhcnMgc2luY2UgRU5VTSB3YXMgZmlyc3QgY2hh cnRlcmVkLCBJbnRlcm5ldCB0ZWxlcGhvbnkgaGFzIGNoYW5nZWQgYSBncmVhdCBkZWFsLiBBcyBv bmUgZXhhbXBsZSwgdG9kYXkgd2ViLWJhc2VkIGFwcGxpY2F0aW9ucyBhcmUgYmVjb21pbmcgbW9y ZSBzaWduaWZpY2FudCB0byBJbnRlcm5ldCB0ZWxlcGhvbnksIGFzIGFyZSBpbnRlbGxpZ2VudCBt b2JpbGUgZGV2aWNlcy4gSW4gdGhlc2UgZW52DQo+IGlyb25tZW50cywgdGhlcmUgZXhpc3RzIGEg Y2FwYWNpdHkgZm9yIHJpY2hlciBxdWVyaWVzIGFuZCByZXNwb25zZXMsIGFzIHdlbGwgYXMgbW9y ZSBzb3BoaXN0aWNhdGVkIGFwcGxpY2F0aW9uIGxvZ2ljIHRvIHByb2Nlc3MgcmVxdWVzdHMsIGJ1 dCBhbHNvIHRvdWdoZXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLiBBcyBzdWNoLCB0aGlzIHdvcmtp bmcgZ3JvdXAgcmVjb25zaWRlcnMgdGhlIG1pZ3JhdGlvbiBvZiByb3V0aW5nIGFuZCBkaXJlY3Rv cnkgZnVuY3Rpb25zIGZyb20gdGhlIHRlbGVwaG9uZSBuZXR3b3JrIHRvIHRoZSBJbnRlcm5ldCBi eSBnZW5lcmFsaXppbmcgdGhlIGJhc2Ugc2VtYW50aWNzIG9mIHF1ZXJpZXMgYW5kIHJlc3BvbnNl cyBpbiBhbiBhYnN0cmFjdCBmcmFtZXdvcmssIGFuZCB0aGVuIGRlZmluaW5nIHBvc3NpYmxlIHRy YW5zcG9ydHMgYW5kIGVuY29kaW5ncyBmb3IgdGhlc2UgbWVzc2FnZXMuDQo+IA0KPiBUaGUgY29t cG9uZW50cyBvZiB0aGUgY2hhcnRlcmVkIHdvcmsgaW5jbHVkZToNCj4gDQo+IDEuIEEgZnJhbWV3 b3JrIGFuZCBpbmZvcm1hdGlvbiBtb2RlbCBmb3IgdGhlIGNvbnN0cnVjdGlvbiBxdWVyaWVzIGFu ZCByZXNwb25zZXMuIFRoZSBpbmZvcm1hdGlvbiBtb2RlbCB3aWxsIHByb3ZpZGUgYW4gYWJzdHJh Y3QgZGVzY3JpcHRpb24gb2YgdGhlIHNlbWFudGljcyBvZiB0aGUgdmFyaW91cyBlbGVtZW50cyBh bmQgYXR0cmlidXRlcyB0aGF0IG1ha2UgdXAgVGVSUSBtZXNzYWdlcy4gVGhlIGZyYW1ld29yayB3 aWxsIGZ1cnRoZXIgZXN0YWJsaXNoIHRoZSBzZW1hbnRpY3Mgb2YgVGVSUSB0cmFuc2FjdGlvbnMs IGRlc2NyaWJlIGhvdyByZXNwb25zZXMgYXJlIG1hdGNoZWQgd2l0aCBxdWVyaWVzLCBhbmQgZ2l2 ZSBhbiBvdmVydmlldyBvZiB0aGUgb3BlcmF0aW9uIG9mIHRoZSBwcm90b2NvbC4gSXQgd2lsbCBm dXJ0aGVybW9yZSBkZXNjcmliZSB0aGUgb3ZlcmFsbCBzZWN1cml0eSBtb2RlbCBvZiBUZVJRLCBp bmNsdWRpbmcgY29uZmlkZW50aWFsaXR5IGFuZCBhY2Nlc3MgY29udHJvbCBtZWFzdXJlcyBuZWNl c3NhcnkgdG8gcHJlc2VydmUgcHJpdmFjeS4NCj4gDQo+IDIuIEEgcHJvY2VzcyBmb3Igc3BlY2lm eWluZyBiaW5kaW5ncyBmb3IgdGhlIGluZm9ybWF0aW9uIG1vZGVsLCB3aGljaCBjb21wcmlzZSB0 cmFuc3BvcnRzIGFuZCBlbmNvZGluZ3MuIFRyYW5zcG9ydHMgc3BlY2lmeSB0aGUgdW5kZXJseWlu ZyBwcm90b2NvbHMgdGhhdCB3aWxsIGVuY2Fwc3VsYXRlIFRlUlEgcXVlcmllcyBhbmQgcmVzcG9u c2VzLiBUaGlzIHdvcmtpbmcgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZWZpbmUgbmV3IHVu ZGVybHlpbmcgcHJvdG9jb2xzLCBidXQgd2lsbCBzcGVjaWZ5IGhvdyB0aGUgdHJhbnNhY3Rpb24g bW9kZWwgb2YgVGVSUSBtYXBzIG9udG8gdGhlc2UgdW5kZXJseWluZyBwcm90b2NvbHMuIFBvdGVu dGlhbCB1bmRlcmx5aW5nIHByb3RvY29scyBpbmNsdWRlIEhUVFAgYW5kIERJQU1FVEVSLiBUaGUg ZW5jb2RpbmcgZGV0ZXJtaW5lcyBob3cgVGVSUSBlbGVtZW50cyBhbmQgYXR0cmlidXRlcyB3aWxs IGJlIHJlbmRlcmVkIGluIHRoZSBvYmplY3QgZm9ybWF0IGNhcnJpZWQgYnkgdGhlIHRyYW5zcG9y dDsgcG90ZW50aWFsIG9iamVjdCBmb3JtYXRzIHdvdWxkIGluY2x1ZGUgSlNPTiBhbmQgWE1MIGFu ZCB3ZWxsIGFzIGxvd2VyLWxheWVyIGVuY29kaW5ncy4gQmluZGluZyBzcGVjaWZpY2F0aW9ucyBt dXN0IGRldGFpbCB0aGVpciBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc2VjdXJpdHkgYW5kIHByaXZh Y3kgcmVxdWlyZW1lbnRzIGRlZmluZWQgaW4gdGhlIGZyYW1ld29yay4NCj4gDQo+IDMuIEEgc2V0 IG9mIG9uZSBvciBtb3JlIGJpbmRpbmdzIGNvbXBsaWFudCB3aXRoIHRoZSBwcm9jZXNzIGRlc2Ny aWJlZCBpbiAoMiksIHdoaWNoIHByb3ZpZGUgYSBjb25jcmV0ZSBpbnN0YW50aWF0aW9uIG9mIHRo ZSBwcm90b2NvbC4gVGhpcyBncm91cCB3aWxsIGJlIGluaXRpYWxseSBjaGFydGVyZWQgdG8gY3Jl YXRlIGEgc2luZ2xlIGJpbmRpbmcsIHRob3VnaCBvdGhlciBtYXkgYmUgYSBwb3RlbnRpYWwgc3Vi amVjdCBmb3Igb25nb2luZyB3b3JrIGFmdGVyIGEgcmVjaGFydC4gVGhlc2UgYmluZGluZ3MgbWF5 IGFjY29tcGFueSBwcm9maWxlcyB0aGF0IGRldGFpbCBwYXJ0aWN1bGFyIHNldHMgb2YgYXR0cmli dXRlcyBvciBlbGVtZW50cyByZWxldmFudCB0byBhIGdpdmVuIGRlcGxveW1lbnQuDQo+IA0KPiBU aGUgVGVSUSB3b3JraW5nIGdyb3VwIHdpbGwgY29vcmRpbmF0ZSB3aXRoIG9uZ29pbmcgd29yayBp biB0aGUgRFJJTktTIHNwYWNlIGluIG9yZGVyIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBUZVJRIGlu Zm9ybWF0aW9uIG1vZGVsIGNvbmZvcm1zIHdpdGggdGhlIG5lZWRzIG9mIHByb3Zpc2lvbmluZyBz eXN0ZW1zLiBXaGVuZXZlciBwb3NzaWJsZSwgVGVSUSB3aWxsIHJldXNlIGV4aXN0aW5nIElFVEYg d29yay4gVGhlIHN5bnRheCBhbmQgc2VtYW50aWNzIG9mIHRlbGVwaG9uZSBudW1iZXJzLCBmb3Ig ZXhhbXBsZSwgaGF2ZSBiZWVuIHRoZSBzdWJqZWN0IG9mIGEgZ3JlYXQgZGVhbCBvZiBwcmV2aW91 cyBJRVRGIHdvcmsgKG5vdGFibHkgUkZDIDM5NjYpLCBhbmQgdGhlIFRlUlEgd29ya2luZyBncm91 cCB3aWxsIHJlbHkgb24gdGhpcyBhbmQgcmVsYXRlZCBwcmlvciB3b3JrLiANCj4gDQo+IEdvYWxz IGFuZCBEZWxpdmVyYWJsZXM6DQo+IA0KPiBBdWcgMjAxMwlTdWJtaXQgRnJhbWV3b3JrIGZvciBU ZWxlcGhvbnkgUmVsYXRlZCBRdWVyaWVzIGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+IE5vdiAyMDEz CVN1Ym1pdCBvbmUgVGVSUSBCaW5kaW5nIGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+IEZlYiAyMDEz CVJlY2hhcnRlciBpZiBhZGRpdGlvbmFsIGJpbmRpbmdzIGFyZSByZXF1aXJlZA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkaXNwYXRjaCBtYWls aW5nIGxpc3QNCj4gZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaXNwYXRjaA0KPiANCg0K From prvs=07823f7211=aallen@blackberry.com Mon Mar 11 08:31:15 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360DE21F8B84 for ; Mon, 11 Mar 2013 08:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.52 X-Spam-Level: X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 fjVvWRzfHaQA for ; Mon, 11 Mar 2013 08:31:14 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id A2E4021F8B83 for ; Mon, 11 Mar 2013 08:31:13 -0700 (PDT) X-AuditID: 0a41282f-b7fa06d000002431-b2-513df8b9d7df Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) by mhs060cnc.rim.net (SBG) with SMTP id E1.B4.09265.9B8FD315; Mon, 11 Mar 2013 10:31:05 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 10:31:04 -0500 From: Andrew Allen To: "dispatch@ietf.org" Thread-Topic: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: Ac4ebW3ea5a769MrTwOAhXMx3SQ+Kw== Date: Mon, 11 Mar 2013 15:31:04 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D26567XMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRmVeSWpSXmKPExsXC5Zyvrbvzh22gwZSt/BZLJy1gdWD0WLLk J1MAY1QDo01SYklZcGZ6nr6dTWJeXn5JYkmqQkpqcbKtkk9qemKOQkBRZllicqWCS2Zxck5i Zm5qkZJCZoqtkomSQkFOYnJqbmpeia1SYkFBal6Kkh2XAgawASrLzFNIzUvOT8nMS7dV8gz2 17WwMLXUNVSy003o5Mm4dmg9W8HtvIo5T48wNzDujO1i5OSQEDCRmNe1iQ3CFpO4cG89kM3F ISSwklFi3fQJ7BDOZkaJ1c8esYJUsQloSew/PJ0JxBYR0JY4uqqLGaRIWKCZUeLOoTdg7SIC HYwSt9qfQVXpSdxePgfMZhFQlZj25w7YPl4BD4mHB3eATWUUkJXYffY6WA2zgLjErSfzmSBu EpBYsuc8M4QtKvHy8T9WCFtRYtmJk2wQ9fkSG5+uZ4KYKShxcuYTlgmMQrOQjJqFpGwWkjKI uI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilEwN6PYwMwgOS9ZrygzVy8vtWQTIygBOGro 72B8+97iEKMAB6MSD2/PW9tAIdbEsuLK3EOMEhzMSiK8KzfZBArxpiRWVqUW5ccXleakFh9i DAKGykRmKe7kfGByyiuJNzYwIJKjJM4rEigaKCSQDkxO2ampBalFMEOZODhBlnJJiRQDU0xq UWJpSUY8KBHGFwNToVQDI8/vhpbzjSIZe3d+dHE/s1n3j7TmlcOrNSICPy1/V7jsYXbVj535 p9eahS+KtWid+t09Xooj4mbKzAc+jKcKtO28D3y3XBQY2aJ5dbHh2TrxQL+5O5/Z5Ojtrllu eczF/ve2lHfCb1ekOt/TSl7zIOtM1xmF92EiAe/cp3DpTlXf1d3J3LT0txJLcUaioRZzUXEi AF3JUe5OAwAA Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 15:31:15 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338D26567XMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Cullen, Dale > From: "Cullen Jennings (fluffy)" > > But the instance ID is in a register sent to trusted providers that > know the users name, credentials etc and can be send in an encrypted > channel. This is a bit different it that it goes to other users. The > analysis is not at the same. This is a bit awkward to read, but I believe that your intention is: When the instance ID is in a REGISTER, it is sent to trusted providers that know the user's name, credentials, etc. already, and it can be sent in an encrypted channel. This proposal (i.e., draft-allen-dispatch-imei-urn-as-instanceid) is different in that the the GRUU containing the IMEI is sent to other users. The analysis is not the same. Please correct me if I'm wrong. But assuming that I'm correct: Yes, draft-allen-dispatch-imei-urn-as-instanceid results in the IMEI being sent t= o other users, embedded in the Contact GRUU. And the privacy analysis of th= at is different from that of a REGISTER. The user that receives the IMEI-containing URI does not have a database mapp= ing the IMEI to the user's name or other data. (Or at least, I don't expect= the service providers to make their database available to subscribers.) So the IMEI-containing URI is reduced from a personal identifier to a "const= ant user fingerprint", an identifier that is associated with just one person= , but anyone who wants to make use of that fact has to figure out themselves= which person it is. And that is the same as any with other GRUU. If one's phone is using a GRUU= , any conversant can record the GRUU and one's name, and use it to identify= further calls from one's self. Of course, if the user intends anonymity, the user can cause the UA to obtai= n a temporary GRUU which is not a constant user fingerprint, as is implied b= y section 8 of the draft. We've already worked through this problem. [AA] response: draft-allen addresses this. The gr parameter is generated from the IME in t= he instance ID but is not the IMEI URN: 7. 3GPP Registrar Procedures In 3GPP IMS when the Registrar receives in the Contact header field a "sip.instance" media feature tag containing the GSMA IMEI URN according to the syntax defined in draft-montemurro-gsma-imei-urn-13 [3] the registrar follows the procedures defined in RFC 5626 [1] and RFC 5627 [2] if those extensions are supported and indicated as supported by the UA. If the Registrar allocates a public GRUU according to the procedures defined in RFC 5627 [2] the instance-id MUST be obfuscated when creating the "gr" parameter in order not to reveal the IMEI to other UAs when the public GRUU is included in non- register requests. 3GPP TS 24.229 [6] subclause 5.4.7A.2 defines the mechanism for obfuscating the IMEI when creating the "gr" parameter. 3GPP TS 24.229 ] subclause 5.4.7A.2 states: If the "+sip.instance" header field parameter from the Contact address conta= ins an IMEI URN, as specified in draft-montemurro-gsma-imei-urn [153], then= the value of the "gr" SIP URI parameter is generated by the S-CSCF using th= e name-based UUID algorithm defined in RFC 4122 [154]. The following applies= to the algorithm: - the namespace shall be a UUID generated for use across the ad= ministrative domain and shall use the algorithm for creating a UUID from tru= ly random numbers specified in RFC 4122 [154]; NOTE: If the generated UUID is changed, then newly created GRUUs will not= match those that were created with the previous UUID. Therefore, the UUID n= eeds to remain the same in order to create consistent GRUUs. - SHA-1 shall be used as the hash algorithm; and - the "name" is made up of a concatenation of the TAC and SNR p= ortions of the IMEI from the "+sip.instance" header field parameter. Andrew --------------------------------------------------------------------- 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. --_000_BBF5DDFE515C3946BC18D733B20DAD2338D26567XMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Cullen, Dale

 

> From: "Cullen Jennings (fluffy)" &l= t;fluffy at cisco.com>

>

> But the instance ID is in a register sent to= trusted providers that

> know the users name, credentials etc and can= be send in an encrypted

> channel. This is a bit different it that it g= oes to other users. The

> analysis is not at the same.

 

This is a bit awkward to read, but I believe that= your intention is:

 

    When the instance ID is in a RE= GISTER, it is sent to trusted

    providers that know the user's= name, credentials, etc. already,

    and it can be sent in an encryp= ted channel.  This proposal (i.e.,

    draft-allen-dispatch-imei-urn-a= s-instanceid) is different in that

    the the GRUU containing the IME= I is sent to other users.  The

    analysis is not the same.<= /o:p>

 

Please correct me if I'm wrong.

 

But assuming that I'm correct:  Yes,

draft-allen-dispatch-imei-urn-as-instanceid result= s in the IMEI being sent to other users, embedded in the Contact GRUU. = And the privacy analysis of that is different from that of a REGISTER.=

 

The user that receives the IMEI-containing URI doe= s not have a database mapping the IMEI to the user's name or other data.&nbs= p; (Or at least, I don't expect the service providers to make their database= available to subscribers.)

 

So the IMEI-containing URI is reduced from a perso= nal identifier to a "constant user fingerprint", an identifier tha= t is associated with just one person, but anyone who wants to make use of th= at fact has to figure out themselves which person it is.

 

And that is the same as any with other GRUU. = If one's phone is using a GRUU, any conversant can record the GRUU and one'= s name, and use it to identify further calls from one's self.

 

Of course, if the user intends anonymity, the user= can cause the UA to obtain a temporary GRUU which is not a constant user fi= ngerprint, as is implied by section 8 of the draft.  We've already work= ed through this problem.

 

[AA] response:

 

draft-allen  addresses this. The gr parameter= is generated from the IME in the instance ID but is not the IMEI URN:<= /o:p>

 

7.  3GPP Registrar Procedures

 

   In 3GPP IMS when the Registrar receiv= es in the Contact header field a

   "sip.instance" media featur= e tag containing the GSMA IMEI URN

   according to the syntax defined in dr= aft-montemurro-gsma-imei-urn-13

   [3] the registrar follows the procedu= res defined in RFC 5626 [1] and

   RFC 5627 [2] if those extensions are= supported and indicated as

   supported by the UA.  If the Reg= istrar allocates a public GRUU

   according to the procedures defined i= n RFC 5627 [2] the instance-id

   MUST be obfuscated when creating the= "gr" parameter in order not to

   reveal the IMEI to other UAs when the= public GRUU is included in non-

   register requests. 3GPP TS 24.229 [6]= subclause 5.4.7A.2 defines the

   mechanism for obfuscating the IMEI wh= en creating the "gr" parameter.

 

 

3GPP TS 24.229 ] subclause 5.4.7A.2 states:

 

If the "+sip.instance" header field= parameter from the Contact address contains an IMEI URN, as specified in dr= aft-montemurro-gsma-imei-urn [153], then the value of the "gr" SIP= URI parameter is generated by the S-CSCF using the name-based UUID algorithm defined in RFC 4122 [154]. The following applies to the algo= rithm:

-        &= nbsp;     the namespace shall be a UUID generated for us= e across the administrative domain and shall use the algorithm for creating= a UUID from truly random numbers specified in RFC 4122 [154];

NOTE:   If the generated UUID is changed= , then newly created GRUUs will not match those that were created with the p= revious UUID. Therefore, the UUID needs to remain the same in order to creat= e consistent GRUUs.

-        &= nbsp;     SHA-1 shall be used as the hash algorithm; and=

-        &= nbsp;     the "name" is made up of a concatena= tion of the TAC and SNR portions of the IMEI from the "+sip.instanc= e" header field parameter.

 

 

 

Andrew

 

---------------------------------------------------------------------
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. --_000_BBF5DDFE515C3946BC18D733B20DAD2338D26567XMB104ADSrimnet_-- From hgs@cs.columbia.edu Mon Mar 11 10:13:43 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB3F21F8C0C for ; Mon, 11 Mar 2013 10:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 mehhyowrfAVt for ; Mon, 11 Mar 2013 10:13:42 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF9D21F8A8F for ; Mon, 11 Mar 2013 10:13:42 -0700 (PDT) Received: from dhcp-521b.meeting.ietf.org (dhcp-521b.meeting.ietf.org [130.129.82.27]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r2BHDeSM025386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Mar 2013 13:13:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Henning Schulzrinne In-Reply-To: <596979554D802045BBD45C051A4399E4025F3B@stntexmb12.cis.neustar.com> Date: Mon, 11 Mar 2013 13:13:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3728EE37-3753-4237-B5E5-0EF503A17363@cs.columbia.edu> References: <596979554D802045BBD45C051A4399E4025F3B@stntexmb12.cis.neustar.com> To: "Peterson, Jon" X-Mailer: Apple Mail (2.1499) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] terq charter revision X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:13:43 -0000 I would consider the ability to update information (of individual = records, not ranges) to be useful, particularly given that this seems = less obvious than in the DNS case. Assuming something like HTTP as = transport, this doesn't seem all that hard. Henning On Mar 11, 2013, at 11:24 AM, "Peterson, Jon" = wrote: > The use cases to date anyway scope TeRQ to information retrieval, not = provisioning. We can make this explicit in the charter if that would be = helpful.=20 >=20 > I have looked a bit a the relationship between this work and WEIRDS, = yes. That too is something we could call out in the charter as another = potential point of appropriation or collaboration.=20 >=20 > Jon Peterson > NeuStar, Inc. >=20 >=20 >=20 > Sent with Good (www.good.com) >=20 >=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, March 10, 2013 10:41 PM Eastern Standard Time > To: Peterson, Jon > Cc: dispatch@ietf.org > Subject: Re: [dispatch] terq charter revision >=20 > Two questions/comments: >=20 > (1) It is not quite clear whether the scope is restricted to retrieval = ("GET") or also updates by authorized entities ("PUT"). For HTTP, it = seems relatively straightforward to specify both, less so for DIAMETER, = but I don't see much of a problem with having several retrieval = mechanisms. >=20 > (2) There is some relationship to the whois retrieval work, I believe. = This should at least be explored. >=20 > Henning >=20 > On Mar 7, 2013, at 6:27 PM, "Peterson, Jon" = wrote: >=20 >>=20 >> Based on the comments previously received, this is a slight revision = to the TeRQ charter. The fundamentals here though are pretty much = unchanged: the plan is to do the framework and information model = document and one binding document, rechartering if there is interest in = doing any further binding documents. >>=20 >> Jon Peterson >> NeuStar, Inc. >>=20 >> --- >>=20 >> Title: Telephony-Related Queries >> Acronym: terq >> Area: Real-time Applications and Infrastructure >> Area Director: TBD >> Chair(s): TBD >> Mailing address: TBD (currently dispatch@ietf.org) >>=20 >> Description of Working Group >>=20 >> Several IETF efforts have studied the handling of telephone numbers = on the Internet. For example, the ENUM working group specified a = DNS-based approach to transforming telephone numbers into URIs; the = DRINKS working group produced a provisioning system suitable for = populating Internet directories of telephone numbers. The overall goal = of this work has been to migrate the routing and directory functions of = the telephone network onto the Internet, in order to simplify the = implementation of Internet telephony and reduce the Internet's reliance = on the infrastructure of the public switched telephone network. = Ultimately, the requirements for this project diverged significantly = from the original architecture and applicability of ENUM. Moreover, in = the twelve years since ENUM was first chartered, Internet telephony has = changed a great deal. As one example, today web-based applications are = becoming more significant to Internet telephony, as are intelligent = mobile devices. In these env >> ironments, there exists a capacity for richer queries and responses, = as well as more sophisticated application logic to process requests, but = also tougher security requirements. As such, this working group = reconsiders the migration of routing and directory functions from the = telephone network to the Internet by generalizing the base semantics of = queries and responses in an abstract framework, and then defining = possible transports and encodings for these messages. >>=20 >> The components of the chartered work include: >>=20 >> 1. A framework and information model for the construction queries and = responses. The information model will provide an abstract description of = the semantics of the various elements and attributes that make up TeRQ = messages. The framework will further establish the semantics of TeRQ = transactions, describe how responses are matched with queries, and give = an overview of the operation of the protocol. It will furthermore = describe the overall security model of TeRQ, including confidentiality = and access control measures necessary to preserve privacy. >>=20 >> 2. A process for specifying bindings for the information model, which = comprise transports and encodings. Transports specify the underlying = protocols that will encapsulate TeRQ queries and responses. This working = group is not chartered to define new underlying protocols, but will = specify how the transaction model of TeRQ maps onto these underlying = protocols. Potential underlying protocols include HTTP and DIAMETER. The = encoding determines how TeRQ elements and attributes will be rendered in = the object format carried by the transport; potential object formats = would include JSON and XML and well as lower-layer encodings. Binding = specifications must detail their implementation of the security and = privacy requirements defined in the framework. >>=20 >> 3. A set of one or more bindings compliant with the process described = in (2), which provide a concrete instantiation of the protocol. This = group will be initially chartered to create a single binding, though = other may be a potential subject for ongoing work after a rechart. These = bindings may accompany profiles that detail particular sets of = attributes or elements relevant to a given deployment. >>=20 >> The TeRQ working group will coordinate with ongoing work in the = DRINKS space in order to make sure that the TeRQ information model = conforms with the needs of provisioning systems. Whenever possible, TeRQ = will reuse existing IETF work. The syntax and semantics of telephone = numbers, for example, have been the subject of a great deal of previous = IETF work (notably RFC 3966), and the TeRQ working group will rely on = this and related prior work.=20 >>=20 >> Goals and Deliverables: >>=20 >> Aug 2013 Submit Framework for Telephony Related Queries as = Proposed Standard >> Nov 2013 Submit one TeRQ Binding as Proposed Standard >> Feb 2013 Recharter if additional bindings are required >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 From michaellundberg.ietf@gmail.com Mon Mar 11 13:53:50 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C051C21F9120 for ; Mon, 11 Mar 2013 13:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 ZRfhJ69WG0CL for ; Mon, 11 Mar 2013 13:53:48 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 995F521F913B for ; Mon, 11 Mar 2013 13:53:47 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id c12so5427148ieb.34 for ; Mon, 11 Mar 2013 13:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=4GOSAlcgcs/PS+LGpL5IQ+d34JXQfwDYKAK3hzdAwh0=; b=S8Q+00YWWOwipy8UI5Fh0yCPgQ3wB39fpKHagSIrrgonD29XsiN3gyqPbu+vARZ3xW GG9p6X8dm094YRTunH9XHHHPkpLOUGIztzeKt0Zyv9j2tu0kTF/h/AEHlZ+ZBLOzs8Vg b06cYqPThkiHh+/rXYM4bGHhsp/jjaDS/5c9xh6jZrDMZSgbgedZpJE1UNhZhC9VcG8n WH1ciM3dciAp3plJoIYLsc5H+XfJNL7RJK1sKHkM0WOY2L0/T98PgSo5/I4tu+GXVo9d YErBRueA9ySMArNJJ7e+IF7wDBFh05Z3QKy5GsSiMR4kW4X1aHQ/D8XxIUtWDraT5F5A clNw== MIME-Version: 1.0 X-Received: by 10.50.11.229 with SMTP id t5mr8945063igb.65.1363035227143; Mon, 11 Mar 2013 13:53:47 -0700 (PDT) Received: by 10.64.53.69 with HTTP; Mon, 11 Mar 2013 13:53:46 -0700 (PDT) In-Reply-To: <513DE174.8000007@stpeter.im> References: <513DE174.8000007@stpeter.im> Date: Mon, 11 Mar 2013 16:53:46 -0400 Message-ID: From: Michael Lundberg To: Peter Saint-Andre Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] Comments on draft-saintandre-sip-xmpp-presence-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 20:53:50 -0000 On Mon, Mar 11, 2013 at 9:51 AM, Peter Saint-Andre wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/9/13 7:29 PM, Michael Lundberg wrote: >> Peter, >> >> Thanks for resubmitting the SIP-XMPP presence I-D. I think this >> and the other documents are important as there are a lot of >> interworking issues today with XMPP and SIP/SIMPLE implementations, >> and I think these documents can help reduce some of those >> interworking challenges. >> >> In order to help ensure interworking between different >> implementations, I think Sections 5.2 and 5.3 need to have some >> stronger =91MUST=92 language instead of SHOULDs, MAYs, etc. This will >> enforce proper and complete mappings between implementations that >> conform to this document. > > Quite possibly. In general I think it might be good to have a > discussion about how strong we want to make the recommendations in > this suite of documents. > >> While I don=92t think the document needs to enforce the use of the >> element mapping discussed in 5.2, I think if >> implementations are going to use the mapping, this document should >> enforce the use of a specific namespace and describe the mapping of >> values specified in RFC 6121 (i.e., away, dnd, chat, and >> xa). > > One option, as I suggested in the I-D, is to use the 'jabber:client' > namespace, for instance: > > away I'm ok with using this namespace. I just want to make sure this isn't left up to whatever namespace the implementer wants to use. Right now the document says we don't need to standardize on this particular issue, and that xmlns=3D'jabber:client' is used in the example. I just want to take it a step further and say that xmlns=3D'jabber:client' should be used for the following presence value mappings x, y, z between XMPP and SIP. > However, I have heard that different presence/IM systems have > different interpretations of the "dnd" (do not disturb) state. So I > think we might need to work that out. I think this is a good point and a good discussion topic. One way to potentially address this is to map 'dnd' from one protocol to some other value or state in another protocol. Alternatively, you could do the one-to-one mapping and leave it up to implementations to address the interpretations of dnd in either a passive or proactive manner. The gateway could send in the 'free text' portion of the presence message whether or not the user can receive messages when he/she is in a 'dnd' state. The gateway could also respond to individuals who try and message a user who is in a 'dnd' state that the "individual can't receive messages". In my opinion, I think this behavior should be left up to implementation. This document may want to suggest some ways that it could be handled. >> This will at least allow a minimum set of standard mappings between >> XMPP and SIP, which can be expanded on in future document(s). >> Section 5.3 could then also discuss how this mapping can be >> accomplished from SIP to XMPP if the SIP endpoints/devices support >> this same namespace. One of the big interworking challenges with >> today=92s implementations is the use of different namespaces given >> the extensibility of XML-based presence standards (e.g., PIDF, >> RPID), which allows individuals to create their own namespace. >> This flexibility is good for ingenuity, but problematic for >> interworking between different implementations. I think >> standardizing a basic set of common status information using a >> specific namespace is needed, and this document is a good place to >> do that. > > That seems helpful. > >> In my opinion, I do not think Section 6 should be part of this >> base document. While I like the idea of encapsulating the SIP >> information into the XMPP message, I think this content >> should be a consideration for implementing =91rich presence=92. As >> written, this method is only applicable for SIP to XMPP >> translation, and if the focus of this document is just =91basic=92 >> presence information interworking, the SIP to XMPP mapping in >> Section 5.3 already describes a method for how this can be >> accomplished. > > IMHO it would be fine to remove Section 6, unless someone really wants > it to be in this spec. > > Thanks for the feedback! > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRPeFzAAoJEOoGpJErxa2pm6sP/3C+XEW4gUcnwHuCT0sHfTYi > YOSzqzK+HT0fHjXRYjRthGu3ZF7qfBv4ak+0oR9GuzxzL49aku9HUcTCN8ZX9132 > i85Fh/UxFGi1kHTu0g+YF1cIHas4niy4EYtZ7IyHoQ1aV1t9M+yvXH+8laEkAJ7V > oBiCFtLMPDd64pXc8pxA8RS5NWgYEoYX89xEOXIh7vApVozT4DcsOmm/DBH7wmxG > 0T/3dBCo6OYtJz0oBYhP8SwyxEQfpz1+2QSUulEfbhUN7ZuBZGNdWLLkxOeQq1gZ > aSLNb6BZkxp2mGrFu2TblTW+E8wz7GVzua41+JvyU9ipXTfkEoDJVTAZTx1tdPDX > HruAIB4p7e3MRFLBzDzYzUqH0OXfjt7EYV93fr9k7GKpGn6/mjlkr6i23b5dz/19 > kZCt4Z9xSOLTxy9t3h2evd6huZrXeqkbCyXW7fB2wGam3/366/TDiYb3MTWxougV > CveADTd3O9BKGobTu1laKaep6+ZqsWIUoYaxw2TFL1edUUqGDNlaw1b3+H1mjwHz > dEFYAjDPMk3qiS7u7nrdTOE3fP4HkMoJoSZjZ+2z3YDpc44X5m1h0YqU4uxOiNsq > Kjai2O3311z5qrZqICkn2l+mJh31JXPt35Jb+F8V2ztAImSf50HMQJFIC1FkMFNG > vKUYWw6m+bj++I8ue21l > =3Dt1Zx > -----END PGP SIGNATURE----- From worley@shell01.TheWorld.com Mon Mar 11 14:54:05 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FD421F90A8 for ; Mon, 11 Mar 2013 14:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 GJJCqRM+QfDm for ; Mon, 11 Mar 2013 14:54:05 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 147C921F90A1 for ; Mon, 11 Mar 2013 14:54:04 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2BLrWNs028964; Mon, 11 Mar 2013 17:53:34 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2BLrVZK234225; Mon, 11 Mar 2013 16:53:31 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2BLrV71231725; Mon, 11 Mar 2013 17:53:31 -0400 (EDT) Date: Mon, 11 Mar 2013 17:53:31 -0400 (EDT) Message-Id: <201303112153.r2BLrV71231725@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Andrew Allen In-reply-to: (aallen@blackberry.com) References: Cc: fluffy@cisco.com, dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 21:54:06 -0000 > From: Andrew Allen > > draft-allen addresses this. The gr parameter is generated from the > IME in the instance ID but is not the IMEI URN: > > 7. 3GPP Registrar Procedures > > In 3GPP IMS when the Registrar receives in the Contact header field a > "sip.instance" media feature tag containing the GSMA IMEI URN > according to the syntax defined in draft-montemurro-gsma-imei-urn-13 > [3] the registrar follows the procedures defined in RFC 5626 [1] and > RFC 5627 [2] if those extensions are supported and indicated as > supported by the UA. If the Registrar allocates a public GRUU > according to the procedures defined in RFC 5627 [2] the instance-id > MUST be obfuscated when creating the "gr" parameter in order not to > reveal the IMEI to other UAs when the public GRUU is included in non- > register requests. 3GPP TS 24.229 [6] subclause 5.4.7A.2 defines the > mechanism for obfuscating the IMEI when creating the "gr" parameter. OK, my mistake that I had not read that section, so my previous response was relative to general SIP usage, not 3GPP-specific usage. I think there are a couple of improvements to 3GPP TS 24.229 that should be made: > 3GPP TS 24.229 ] subclause 5.4.7A.2 states: > > If the "+sip.instance" header field parameter from the Contact > address contains an IMEI URN, as specified in > draft-montemurro-gsma-imei-urn [153], then the value of the "gr" SIP > URI parameter is generated by the S-CSCF using the name-based UUID > algorithm defined in RFC 4122 [154]. The following applies to the > algorithm: > > - the namespace shall be a UUID generated for use across the > administrative domain and shall use the algorithm for creating a > UUID from truly random numbers specified in RFC 4122 [154]; "namespace" here should be "name space ID", to match the terminology in RFC 4122 section 4.3. Also, for clarity there should be a more explicit separation of the description of the generation of the "name space ID" URI and the "gr" parameter: - the "name space ID" shall be a UUID generated for use across the administrative domain for this purpose. The name space ID shall be kept confidential by the administrative domain and shall be generated using the algorithm for creating a UUID from truly random numbers specified in RFC 4122 [154]; That also states explicitly that the name space ID should be kept confidential. > NOTE: If the generated UUID is changed, then newly created GRUUs > will not match those that were created with the previous > UUID. Therefore, the UUID needs to remain the same in order to > create consistent GRUUs. > > - SHA-1 shall be used as the hash algorithm; and > > - the "name" is made up of a concatenation of the TAC and SNR > portions of the IMEI from the "+sip.instance" header field > parameter. Strictly speaking, the "name" part of the input to SHA-1 in this algorithm is a sequence of octets, whereas the IMEI URN is a sequence of Unicode characters. We want to make sure that it is clear that the "name" is the representation of the TAC and SNR in ordinary ASCII/UTF-8. Normally this would be obvious, but in mobile use, the TAC and SNR digits are often packed into half-octets: - the "name" is made up of a concatenation of the TAC and SNR portions of the IMEI from the "+sip.instance" header field parameter, represented as octets containing the ASCII encodings of the digits. Dale From ietf@meetecho.com Mon Mar 11 15:44:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6178B21F8A8E for ; Mon, 11 Mar 2013 15:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.607 X-Spam-Level: X-Spam-Status: No, score=-0.607 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 bo1Fm4AzTc-m for ; Mon, 11 Mar 2013 15:44:22 -0700 (PDT) Received: from smtpdg4.aruba.it (smtpdg222.aruba.it [62.149.158.222]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBCA21F8A08 for ; Mon, 11 Mar 2013 15:44:13 -0700 (PDT) Received: from meetecho ([130.129.6.44]) by smtpcmd02.ad.aruba.it with bizsmtp id ANk91l00S0wzZHu01NkBsp; Mon, 11 Mar 2013 23:44:12 +0100 Date: Mon, 11 Mar 2013 18:43:37 -0700 (PDT) From: Meetecho Team To: dispatch@ietf.org Message-ID: <26905665.3.1363052617022.JavaMail.root@meetecho> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2_13555426.1363052617018" Subject: [dispatch] DISPATCH session recording available X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:44:23 -0000 ------=_Part_2_13555426.1363052617018 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the DISPATCH WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#IETF86_DISPATCH In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_2_13555426.1363052617018-- From richard@shockey.us Mon Mar 11 17:25:04 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E3121F8F3C for ; Mon, 11 Mar 2013 17:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.673 X-Spam-Level: X-Spam-Status: No, score=-98.673 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PENIS1=3.592, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 5p+k25RLkS48 for ; Mon, 11 Mar 2013 17:25:03 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 2202A21F8F39 for ; Mon, 11 Mar 2013 17:25:03 -0700 (PDT) Received: (qmail 12400 invoked by uid 0); 12 Mar 2013 00:24:38 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 12 Mar 2013 00:24:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=NTsoHL8ZFoF1Hp4f7n/zWTu4TSRS2VrhPZhTHKcrimI=; b=eOaHf59yXC0ncU+422y3/QXrU/neznGXOxtnnC+dBLervbwbMgAQkgy460e1lGQGFkZac2oyVgkGvJZqSuBkTh7YFn0lnY36qpNfSWlhljxH/1GHKtL9VDZvRDGUrMcs; Received: from [69.162.16.18] (port=49994 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UFD1B-0002Ud-V8 for dispatch@ietf.org; Mon, 11 Mar 2013 18:24:38 -0600 From: "Richard Shockey" To: References: <55A5A9A87506CB4BA580BF9D531957DA921A0424@STNTEXCH01.cis.neustar.com> <38726EDA2109264987B45E29E758C4D61D3572@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D61D3572@MISOUT7MSGUSR9N.ITServices.sbc.com> Date: Mon, 11 Mar 2013 20:24:37 -0400 Message-ID: <00c401ce1eb7$fae9fc50$f0bdf4f0$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 thread-index: AQI2AzvcxVjh08+jIPSGjz2K4Pp3xQK9Yq47l7rrp7A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 69.162.16.18 authed with richard@shockey.us} Subject: Re: [dispatch] terq charter revision X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 00:25:04 -0000 +1 to these issues not to mention the larger problem of given the glacial pace work moves through the IETF will this effort actually have any significant impact on the real world requirements. That said the limitations of the DNS model for number resolution have been well known and required endless duct tape and bailing wire workarounds which is why many operators adopted a database model based on SIP Redirect. That said I certainly have no objections to moving this forward. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L Sent: Monday, March 11, 2013 8:50 AM To: Peterson, Jon; dispatch@ietf.org Subject: Re: [dispatch] terq charter revision Jon: I still have some questions about this enterprise: 1. What will be the basis for the information model to be developed? Will it address the needs of the service providers and regulators that currently control the E.164 space or is it end user/webRTC focused? Or both? 2. What was attractive about ENUM was the way in which it leveraged an existing protocol and ecosystem to make telephone numbers fit into IP. I'm not quite sure how to think of the current effort in those terms. 3. w/r/t to "richer queries and responses" and " more sophisticated application logic", the only thing that richer seems to mean is source-based. Do we really need a new framework for that? And people have already found ways to apply more sophisticated application logic by putting an ENUM front end on a relational database. 4. The statement about making sure the information model conforms to the needs of the provisioning systems concerns me in that, if we're taking the trouble to define an information model de novo, the dictates of the model ought to take precedence over the provisioning system rather than be restricted by it. 5. If we're serious about defining an encompassing information model I think a framework by August 2013 is way optimistic, unless there's something waiting in the wings. Penn Pfautz AT&T +1-732-420-4962 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Thursday, March 07, 2013 6:27 PM To: dispatch@ietf.org Subject: [dispatch] terq charter revision Based on the comments previously received, this is a slight revision to the TeRQ charter. The fundamentals here though are pretty much unchanged: the plan is to do the framework and information model document and one binding document, rechartering if there is interest in doing any further binding documents. Jon Peterson NeuStar, Inc. --- Title: Telephony-Related Queries Acronym: terq Area: Real-time Applications and Infrastructure Area Director: TBD Chair(s): TBD Mailing address: TBD (currently dispatch@ietf.org) Description of Working Group Several IETF efforts have studied the handling of telephone numbers on the Internet. For example, the ENUM working group specified a DNS-based approach to transforming telephone numbers into URIs; the DRINKS working group produced a provisioning system suitable for populating Internet directories of telephone numbers. The overall goal of this work has been to migrate the routing and directory functions of the telephone network onto the Internet, in order to simplify the implementation of Internet telephony and reduce the Internet's reliance on the infrastructure of the public switched telephone network. Ultimately, the requirements for this project diverged significantly from the original architecture and applicability of ENUM. Moreover, in the twelve years since ENUM was first chartered, Internet telephony has changed a great deal. As one example, today web-based applications are becoming more significant to Internet telephony, as are intelligent mobile devices. In these env ironments, there exists a capacity for richer queries and responses, as well as more sophisticated application logic to process requests, but also tougher security requirements. As such, this working group reconsiders the migration of routing and directory functions from the telephone network to the Internet by generalizing the base semantics of queries and responses in an abstract framework, and then defining possible transports and encodings for these messages. The components of the chartered work include: 1. A framework and information model for the construction queries and responses. The information model will provide an abstract description of the semantics of the various elements and attributes that make up TeRQ messages. The framework will further establish the semantics of TeRQ transactions, describe how responses are matched with queries, and give an overview of the operation of the protocol. It will furthermore describe the overall security model of TeRQ, including confidentiality and access control measures necessary to preserve privacy. 2. A process for specifying bindings for the information model, which comprise transports and encodings. Transports specify the underlying protocols that will encapsulate TeRQ queries and responses. This working group is not chartered to define new underlying protocols, but will specify how the transaction model of TeRQ maps onto these underlying protocols. Potential underlying protocols include HTTP and DIAMETER. The encoding determines how TeRQ elements and attributes will be rendered in the object format carried by the transport; potential object formats would include JSON and XML and well as lower-layer encodings. Binding specifications must detail their implementation of the security and privacy requirements defined in the framework. 3. A set of one or more bindings compliant with the process described in (2), which provide a concrete instantiation of the protocol. This group will be initially chartered to create a single binding, though other may be a potential subject for ongoing work after a rechart. These bindings may accompany profiles that detail particular sets of attributes or elements relevant to a given deployment. The TeRQ working group will coordinate with ongoing work in the DRINKS space in order to make sure that the TeRQ information model conforms with the needs of provisioning systems. Whenever possible, TeRQ will reuse existing IETF work. The syntax and semantics of telephone numbers, for example, have been the subject of a great deal of previous IETF work (notably RFC 3966), and the TeRQ working group will rely on this and related prior work. Goals and Deliverables: Aug 2013 Submit Framework for Telephony Related Queries as Proposed Standard Nov 2013 Submit one TeRQ Binding as Proposed Standard Feb 2013 Recharter if additional bindings are required _______________________________________________ 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 fluffy@cisco.com Mon Mar 11 18:35:12 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F4821F8640 for ; Mon, 11 Mar 2013 18:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 6v3kUGHh97Ks for ; Mon, 11 Mar 2013 18:35:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AD64721F85D8 for ; Mon, 11 Mar 2013 18:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=110; q=dns/txt; s=iport; t=1363052103; x=1364261703; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nEBz7K/rn2kBu5M8aVcKWmjDLAU9LKrb+/3nfxpqS70=; b=lZT89HsY6KfUFJXcrURxVU3sjVvScVs2U3a3usT2nIbpO/kpXay1P85M U6zGHpAJq4W9WqplOfNDyTxb+jCSFIEDfJNl8PIIo5hH41/Ytx8wbTjVx DDRtTsr2nSHz7t8ej5my2hQj+xrU9gA7tKHq0sLILSij6OoGsdhGWSKj3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFANqEPlGtJXG9/2dsb2JhbAA6CYdkvQKBXxZ0gioBAQQ6PxACAQgiFBAyJQIEDg2ICwyvVpAdBI1UgQkxB4JfYQOnSoMKgig X-IronPort-AV: E=Sophos;i="4.84,827,1355097600"; d="scan'208";a="186131763" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 12 Mar 2013 01:35:00 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2C1YxFL003310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 01:34:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 20:34:59 -0500 From: "Cullen Jennings (fluffy)" To: Peter Saint-Andre Thread-Topic: [dispatch] URI schemes in P-Asserted-Identity Thread-Index: AQHOGAsUJhdVcbJHkUyhphnvwmWC1Jif0DqJgAHXHgA= Date: Tue, 12 Mar 2013 01:34:59 +0000 Message-ID: References: <51102D21.10503@stpeter.im> <513D415B.7060505@stpeter.im> In-Reply-To: <513D415B.7060505@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.1.189] Content-Type: text/plain; charset="us-ascii" Content-ID: <8C72DA38EF822847A7B3F259C3A3D061@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , Emil Ivov Subject: Re: [dispatch] URI schemes in P-Asserted-Identity X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 01:35:12 -0000 >>=20 >=20 > https://datatracker.ietf.org/doc/draft-saintandre-impp-call-info/ >=20 Looks good to me From prvs=776c2331a=christou_chris@bah.com Mon Mar 11 19:05:14 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA1221F8B64 for ; Mon, 11 Mar 2013 19:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ehr3+ZcFq9wB for ; Mon, 11 Mar 2013 19:05:12 -0700 (PDT) Received: from mclniron02-ext.bah.com (mclniron02-ext.bah.com [128.229.5.22]) by ietfa.amsl.com (Postfix) with ESMTP id 83EB121F8996 for ; Mon, 11 Mar 2013 19:05:12 -0700 (PDT) x-SBRS: None X-REMOTE-IP: 10.12.10.57 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAIeMPlEKDAo5/2dsb2JhbABDiCu8O2qBC3SCKQEBAQQBAQEgEToXBgEZAwECAwIGIAIEJQsUAQYCCQEEEwgBC4gLrRaCQJAggSONOhYQGIInMmEDl3OKQYgTDYIo X-IronPort-AV: E=Sophos;i="4.84,827,1355115600"; d="scan'208";a="476036587" Received: from ashbcshb03.resource.ds.bah.com ([10.12.10.57]) by mclniron02-int.bah.com with ESMTP; 11 Mar 2013 22:05:10 -0400 Received: from ASHBDAG1M1.resource.ds.bah.com ([169.254.1.219]) by ASHBCSHB03.resource.ds.bah.com ([10.12.10.57]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 22:05:10 -0400 From: "Christou, Christos [USA]" To: "DISPATCH (dispatch@ietf.org)" Thread-Topic: I-D Action: draft-christou-sip-xmpp-interop-00.txt Thread-Index: Ac4exP19Jc+NtTS+QWyRZy6KKQzi2Q== Date: Tue, 12 Mar 2013 02:05:09 +0000 Message-ID: <462D69106F82344E95BC83996D8039D259FCE5F4@ASHBDAG1M1.resource.ds.bah.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.5.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [dispatch] Fwd: I-D Action: draft-christou-sip-xmpp-interop-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 02:05:14 -0000 QWxsLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHRoYXQgZGVzY3JpYmVzIHRoZSBkaWZm ZXJlbnQgdHlwZXMgb2YgU0lQIHRvIFhNUFAgaW50ZXJvcGVyYWJpbGl0eSB1c2UgY2FzZXMuICBJ dCBwcmltYXJpbHkgc2VydmVzIGFzIGFuIG92ZXJ2aWV3IHR5cGUgb2YgZG9jdW1lbnQgdG8gZGVm aW5lIHRoZSBkaWZmZXJlbnQgU0lQIGFuZCBYTVBQIHVzZSBjYXNlcyB0aGF0IG1pZ2h0IGV4aXN0 IGFtb25nIFNlcnZpY2UgUHJvdmlkZXJzIGFuZCBpbXBsZW1lbnRlcnMuIEluIGFkZGl0aW9uLCBp dCBwb2ludHMgdG8gb3RoZXIgZG9jdW1lbnRzIChlLmcuLCBDVVNBWCwgU0lQLVhNUFAgaW50ZXJ3 b3JraW5nIGRvY3VtZW50cykgd2hlcmUgdGhlIHJlbGV2YW50IGludGVyd29ya2luZyBmdW5jdGlv bnMgYXJlIGRlZmluZWQuDQoNClBsZWFzZSBwcm92aWRlIGFueSBmZWVkYmFjayBmb3IgdGhpcyBk b2N1bWVudCwgZXNwZWNpYWxseSBhcyB3ZSBjb250aW51ZSB0byBmaW5hbGl6ZSB0aGUgU0lQLVhN UFAgSW50ZXJ3b3JraW5nIGFuZCBDVVNBWCBkb2NzLg0KDQoNCg0KLS0tLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtY2hyaXN0b3Utc2lw LXhtcHAtaW50ZXJvcC0wMC50eHQNCkRhdGU6IFN1biwgMTAgTWFyIDIwMTMgMTg6NTA6MTIgLTA3 MDANCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KUmVwbHktVG86IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZw0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KDQoNCkEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy4NCg0KDQoJVGl0bGUgICAgICAgICAgIDogSW50ZXJvcGVyYWJpbGl0eSBiZXR3 ZWVuIHRoZSBTZXNzaW9uIEluaXRpYXRpb24NClByb3RvY29sIChTSVApIGFuZCB0aGUgRXh0ZW5z aWJsZSBNZXNzYWdpbmcgYW5kIFByZXNlbmNlIFByb3RvY29sIChYTVBQKQ0KCUF1dGhvcihzKSAg ICAgICA6IENocmlzIENocmlzdG91DQogICAgICAgICAgICAgICAgICAgICAgICAgIE1pY2hhZWwg THVuZGJlcmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hyaXN0b3BoZXIgUm9zcw0KICAg ICAgICAgICAgICAgICAgICAgICAgICBQZXRlciBTYWludC1BbmRyZQ0KCUZpbGVuYW1lICAgICAg ICA6IGRyYWZ0LWNocmlzdG91LXNpcC14bXBwLWludGVyb3AtMDAudHh0DQoJUGFnZXMgICAgICAg ICAgIDogNw0KCURhdGUgICAgICAgICAgICA6IDIwMTMtMDMtMTANCg0KQWJzdHJhY3Q6DQogICBU aGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIHNlcnZlIGFzIGEgcmVmZXJlbmNlIHBvaW50IGZv cg0KICAgZGV2ZWxvcGVycyBhbmQgb3BlcmF0b3JzIGltcGxlbWVudGluZyB0aGUgU2Vzc2lvbiBJ bml0aWF0aW9uIFByb3RvY29sDQogICAoU0lQKSBhbmQgdGhlIEV4dGVuc2libGUgTWVzc2FnaW5n IGFuZCBQcmVzZW5jZSBQcm90b2NvbCAoWE1QUCkNCiAgIHdpdGhpbiB0aGVpciBuZXR3b3Jrcy4g IFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgZGVmaW5lIGFueSBuZXcNCiAgIHByb3RvY29scyBidXQg ZG9lcyBkZWZpbmUgdGhlIGRpZmZlcmVudCByZWZlcmVuY2UgbW9kZWxzIGZvcg0KICAgZGVwbG95 bWVudCBvZiBjb21iaW5lZCB1c2Ugb2YgU0lQIGFuZCBYTVBQICgiQ1VTQVgiKSBjbGllbnRzIGFu ZCBTSVAtDQogICBYTVBQIGludGVyd29ya2luZyB0byBlbnN1cmUgY29uc2lzdGVuY3kgYWNyb3Nz IHRoZSBjb21tdW5pdHkuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1j aHJpc3RvdS1zaXAteG1wcC1pbnRlcm9wDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNp b24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hyaXN0 b3Utc2lwLXhtcHAtaW50ZXJvcC0wMA0KDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFp bGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJbnRlcm5ldC1E cmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvciBmdHA6 Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQoNCg== From mary.ietf.barnes@gmail.com Tue Mar 12 06:33:48 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7968E21F8B2B; Tue, 12 Mar 2013 06:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.831 X-Spam-Level: X-Spam-Status: No, score=-102.831 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 nZLMAPZECkJd; Tue, 12 Mar 2013 06:33:48 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DDC6A21F875C; Tue, 12 Mar 2013 06:33:47 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id d1so2009016qca.2 for ; Tue, 12 Mar 2013 06:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=ArG1vbAHUe9XFUQHN6H4QdSU/TdMn0TOyDjmgFpo0Go=; b=SUVJNx7TUdImLoclVqy+bGfMCGGAZ9bE4pUsc/9aJAM4+N95pVqYu1/9xllgVbg2lG 2Ab9VJ+xm2AH69BEULSF4v7vDkZzjq/yk3lBGrqTcFLtVgS5L8W1/rhIspvNl51AiZFA w8eVWrWK+n71E9/qzkc9lUETJOSHbbomaEfdfxzmPEiWQWwX6s+tGvKpL9QOGnhJFKUT +BCubaSKpfs7/5QfGb3vX50wNl/LPdmB5DhEyNFzlAPG/6swbROD/nONbbcm4rVJFIfP 403mwaXW9/OzqM/qf12vCn8UHJ9jCc2h16IuBltygDB9G7FOPPo8GN/Xjir2i0Yj+s8H eIaQ== MIME-Version: 1.0 X-Received: by 10.229.171.3 with SMTP id f3mr5257488qcz.41.1363095227277; Tue, 12 Mar 2013 06:33:47 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Tue, 12 Mar 2013 06:33:46 -0700 (PDT) Date: Tue, 12 Mar 2013 08:33:46 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH Subject: [dispatch] WCIT Bof X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:33:48 -0000 Hi all, Since the AVTCORE WG session on Thursday afternoon was cancelled (17:30-18:30), folks might be interested in attending the WCIT Bof. Rather than summarize myself what it is, the agenda has some background: https://datatracker.ietf.org/meeting/86/agenda/iab-wcit/ Some of this may eventually (and likely will) impact SIP networks/service providers. Regards, Mary. From mary.ietf.barnes@gmail.com Tue Mar 12 07:02:08 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1048911E80AE for ; Tue, 12 Mar 2013 07:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.759 X-Spam-Level: X-Spam-Status: No, score=-103.759 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 IxQ3NR00aSNn for ; Tue, 12 Mar 2013 07:02:07 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 487D611E80AD for ; Tue, 12 Mar 2013 07:02:07 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id q19so2979190qeb.34 for ; Tue, 12 Mar 2013 07:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iFAw9AW4SHCJ7YeHqSeiGxYsntWurk2/54j8n4bAsr4=; b=MNaenyb1hhEy9wBhVALvoCD9cMRDRGBD4P/zp0OikypwI57BmxIP93kQY2tkQRC0+o H7DX6/e5/nEoD2Ynv6Hyg+MM3LYRTS05EXBmNuV9gAjvqtdSiUcr8587hDOn4KSCIizo ow3O/IpzF6c3qBnblVKswL3gBOGkkk/vxFpdjCFfpMWXhzfb70mTtFBrghllLoO18U4M ZEgC1dTx4LQoxDqnfyl8CrYyDdW0XgqU2Of0nsICz3Ybh4RWurpin17V4jM7U4HsqE+9 uPdA+mRIDJMOfVNixpU73nr4elSwB9xeort0FqI951mLderm5sE8qI/Vs4gIqofGNo8U WVSA== MIME-Version: 1.0 X-Received: by 10.229.202.132 with SMTP id fe4mr5371129qcb.14.1363096926621; Tue, 12 Mar 2013 07:02:06 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Tue, 12 Mar 2013 07:02:06 -0700 (PDT) In-Reply-To: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2013 09:02:06 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , Richard Barnes , Victor Pascual , "rai-ads@tools.ietf.org" Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:02:08 -0000 Hi all, As discussed in the DISPATCH WG session, we are doing an official call for comments/agreement to move this work item to the BFCPbis WG. If folks could please respond if they support this or provide comments if you do not. As discussed in the meeting, if we get agreement, the chairs/ADs would update BFCPbis WG charter to include this work item and forward to WG and IESG for review/approval. The WG would then need to decide whether to adopt this specific document towards that WG deliverable. Please respond no later than Friday, March 22nd, 2013. Silence will be taken as agreement. Thanks, Mary DISPATCH WG co-chair On Thu, Feb 21, 2013 at 11:38 AM, Victor Pascual Avila wrote: > Hi all, > > We have submitted a new Internet draft to describe the WebSocket > Protocol as a Transport for the Binary Floor Control Protocol (BFCP). > We are looking forward to your review comments. > > http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 > > Best regards, > -Victor > > > On 2/15/13 6:17 PM, "internet-drafts@ietf.org" > wrote: > >> >>A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt >>has been successfully submitted by Victor Pascual and posted to the >>IETF repository. >> >>Filename: draft-pascual-dispatch-bfcp-websocket >>Revision: 00 >>Title: The WebSocket Protocol as a Transport for the Binary Floor >>Control Protocol (BFCP) >>Creation date: 2013-02-15 >>Group: Individual Submission >>Number of pages: 9 >>URL: >>http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-websocket- >>00.txt >>Status: >>http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket >>Htmlized: >>http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >> >> >>Abstract: >> The WebSocket protocol enables two-way realtime communication between >> clients and servers. This document specifies a new WebSocket sub- >> protocol as a reliable transport mechanism between Binary Floor >> Control Protocol (BFCP) entities to enable usage of BFCP in new >> scenarios. This document normatively updates >> [I-D.draft-ietf-bfcpbis-rfc4582bis] and >> [I-D.draft-ietf-bfcpbis-rfc4583bis] >> >> >> >> >> >>The IETF Secretariat >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From atle.monrad@ericsson.com Tue Mar 12 07:07:24 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E8421F859B for ; Tue, 12 Mar 2013 07:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 8x347h9Jx5Fj for ; Tue, 12 Mar 2013 07:07:23 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 95B5021F89C3 for ; Tue, 12 Mar 2013 07:07:22 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-3e-513f36987d4a Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D5.26.10459.8963F315; Tue, 12 Mar 2013 15:07:21 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.183]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 15:07:20 +0100 From: Atle Monrad To: "Dale R. Worley" , Andrew Allen , Gonzalo Camarillo , "fluffy@cisco.com" Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQHNx0LDMMCAzJYzhkOmkNSi4UyFuJhRn9YA//+gKOCAQtLGgIABHu6AgAsFzeKAAFSzgIAAsajAgAB5i3iAAQS9sA== Date: Tue, 12 Mar 2013 14:07:19 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C080984@ESESSMB203.ericsson.se> References: <201303112153.r2BLrV71231725@shell01.TheWorld.com> In-Reply-To: <201303112153.r2BLrV71231725@shell01.TheWorld.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvje5MM/tAgyfruS3uz9vKaLF00gJW i47JbBYNK04wWrw8UebA6jF5/1dmj1kNa9k9pvzeyOqxZMlPpgCWKC6blNSczLLUIn27BK6M xfvfMRX81qj49ncXewPjXoUuRk4OCQETifvzG1ggbDGJC/fWs3UxcnEICRxilHj+4A2Us4RR 4sue2WBVbAI6Eud+3mEFSYgIrGOUuDppDiNIglkgQWJO9ylGkISwQDOjxIbDG1hBEiICLYwS 9/54QNhZEq/+3AebxCKgKvFi+RM2EJtXwFtiVdcuZoh1/xklPq46CjaVU8Be4v6XBUCDODgY BWQl5jbxQiwTl7j1ZD4TxN0CEkv2nGeGsEUlXj7+xwphK0p8fLUP6jgdiQW7P7FB2NoSyxa+ ZobYKyhxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYmTPTczMSS833MQIjKuDW37r7mA8dU7k EKM0B4uSOG+Y64UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYztlouLFwUunBue7PpreuO7 5ZekDilfiRb4/5V/6cLDM4NPhJa3xl2sEajz6/WeL3b0uJD8i8RADQH/RWvt3nt+a/54Pyg1 4dzXWUqBNyrFuG4vdrA/8WnBJ/8PWZ7ecsIv02eFPXeoW2OS/Kz62UnvSbsMc5cWiBmXBf4/ UnSZb/KDLSuOaXMosRRnJBpqMRcVJwIAEziHmnkCAAA= Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:07:24 -0000 Dale / all If we can do improvements for 3GPP (in TS 24.229), I am sure that Andrew ta= ke your point and bring this back to 3GPP. Our specs are open to proposed i= mprovements which are considered when provided by the 3GPP member companies= . The draft-montemurro-gsma-imei-urn has been around for long time now. 3GPP = has this draft on their list of dependencies, as have GSMA. The draft is im= plemented in 3GPP since Rel-8. We have had conf-calls and discussed this ba= ck and forth for years. Andrew has as I see it, done his best to answer all comments and concerns. There are not too many persons involved in this. I think it would be useful if people that still have issues could look at t= he most recent versions of the drafts and if they think their concerns are = not resolved, bring it up again and not only point to previous mails that A= ndrew think he has answered. Another option is to agree that we don't agree and bring the draft forward = in the process towards RFC based on this conclusion. IMHO, we need a conlusion on this draft now. Thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com]=20 Sent: 11. mars 2013 17:54 To: Andrew Allen Cc: fluffy@cisco.com; Gonzalo Camarillo; Atle Monrad; jbakker@blackberry.co= m; dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted > From: Andrew Allen >=20 > draft-allen addresses this. The gr parameter is generated from the=20 > IME in the instance ID but is not the IMEI URN: >=20 > 7. 3GPP Registrar Procedures >=20 > In 3GPP IMS when the Registrar receives in the Contact header field a > "sip.instance" media feature tag containing the GSMA IMEI URN > according to the syntax defined in draft-montemurro-gsma-imei-urn-13 > [3] the registrar follows the procedures defined in RFC 5626 [1] and > RFC 5627 [2] if those extensions are supported and indicated as > supported by the UA. If the Registrar allocates a public GRUU > according to the procedures defined in RFC 5627 [2] the instance-id > MUST be obfuscated when creating the "gr" parameter in order not to > reveal the IMEI to other UAs when the public GRUU is included in non- > register requests. 3GPP TS 24.229 [6] subclause 5.4.7A.2 defines the > mechanism for obfuscating the IMEI when creating the "gr" parameter. OK, my mistake that I had not read that section, so my previous response wa= s relative to general SIP usage, not 3GPP-specific usage. I think there are a couple of improvements to 3GPP TS 24.229 that should be= made: > 3GPP TS 24.229 ] subclause 5.4.7A.2 states: >=20 > If the "+sip.instance" header field parameter from the Contact address=20 > contains an IMEI URN, as specified in draft-montemurro-gsma-imei-urn=20 > [153], then the value of the "gr" SIP URI parameter is generated by=20 > the S-CSCF using the name-based UUID algorithm defined in RFC 4122=20 > [154]. The following applies to the > algorithm: > > - the namespace shall be a UUID generated for use across the > administrative domain and shall use the algorithm for creating a > UUID from truly random numbers specified in RFC 4122 [154]; "namespace" here should be "name space ID", to match the terminology in RFC= 4122 section 4.3. Also, for clarity there should be a more explicit separ= ation of the description of the generation of the "name space ID" URI and t= he "gr" parameter: - the "name space ID" shall be a UUID generated for use across the administrative domain for this purpose. The name space ID shall be kept confidential by the administrative domain and shall be generated using the algorithm for creating a UUID from truly random numbers specified in RFC 4122 [154]; That also states explicitly that the name space ID should be kept confident= ial. > NOTE: If the generated UUID is changed, then newly created GRUUs > will not match those that were created with the previous UUID.=20 > Therefore, the UUID needs to remain the same in order to create=20 > consistent GRUUs. > > - SHA-1 shall be used as the hash algorithm; and > > - the "name" is made up of a concatenation of the TAC and SNR > portions of the IMEI from the "+sip.instance" header field > parameter. Strictly speaking, the "name" part of the input to SHA-1 in this algorithm = is a sequence of octets, whereas the IMEI URN is a sequence of Unicode char= acters. We want to make sure that it is clear that the "name" is the repre= sentation of the TAC and SNR in ordinary ASCII/UTF-8. Normally this would = be obvious, but in mobile use, the TAC and SNR digits are often packed into= half-octets: - the "name" is made up of a concatenation of the TAC and SNR portions of the IMEI from the "+sip.instance" header field parameter, represented as octets containing the ASCII encodings of the digits. Dale From prvs=6783dc7c12=aallen@blackberry.com Tue Mar 12 08:14:49 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D9321F8917 for ; Tue, 12 Mar 2013 08:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=-2.252, BAYES_00=-2.599, MANGLED_PRBLMS=2.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_FRAUD_X3=1.667] 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 bDxZ7TPfaiH8 for ; Tue, 12 Mar 2013 08:14:44 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id D7BE421F84FF for ; Tue, 12 Mar 2013 08:14:43 -0700 (PDT) X-AuditID: 0a412830-b7ef86d00000339d-bb-513f465710b1 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 36.A5.13213.7564F315; Tue, 12 Mar 2013 10:14:31 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 10:14:29 -0500 From: Andrew Allen To: Atle Monrad , "Dale R. Worley" , Gonzalo Camarillo , "fluffy@cisco.com" Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQHNx0LDMMCAzJYzhkOmkNSi4UyFuJhRn9YA//+gKOCAQtLGgIABHu6AgAsFzeKAAFSzgIAAsajAgAB5lz2AAWOsgP//vmvQ Date: Tue, 12 Mar 2013 15:14:28 +0000 Message-ID: References: <201303112153.r2BLrV71231725@shell01.TheWorld.com> <7D2F7D7ADBA812449F25F4A69922881C080984@ESESSMB203.ericsson.se> In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C080984@ESESSMB203.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDKsWRmVeSWpSXmKPExsXC5ZyvqxvuZh9o0PTX2uL8pjmMFksnLWC1 6JjMZrFp+Uomi5cnyhxYPSbv/8rsMeX3RlaPX1+vsnksWfKTKYAlqoHRJimxpCw4Mz1P384m MS8vvySxJFUhJbU42VbJJzU9MUchoCizLDG5UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3 Na/EVimxoCA1L0XJjksBA9gAlWXmKaTmJeenZOal2yp5BvvrWliYWuoaKtnpJnTyZPzZf5O5 4NBvloqT3SsYGxiv/2LuYuTkkBAwkVh1ZikThC0mceHeejYQW0igjUni8Ga3LkYuIHszo0T7 ywtgRWwCWhL7D09nAkmICGxglDh4ajFYglkgXOLthU3MIAlhgWZGiQ2HN7CCJEQEWhgl7v3x gLDzJBo6noI1sAioSlz+vR9sHa+Ah8TlyWtZIVYfZJKYdl4WxOYU8JG4197IAmIzAp33/dQa qGXiEreezIc6W0BiyZ7zUO+ISrx8/I8VwlaUmLFnPitEvY7Egt2f2CBsbYllC18zQ+wVlDg5 8wnLBEaxWUjGzkLSMgtJyywkLQsYWVYxCuZmFBuYGSbnJesVZebq5aWWbGIEJRdHDYMdjO/f WxxiFOBgVOLhLZa0DxRiTSwrrsw9xCjBwawkwpux2S5QiDclsbIqtSg/vqg0J7X4EKMrMFQm MktxJ+cDE19eSbyxgQFujpI4r0igaKCQQDowOWWnphakFsHMYeLgBNnDJSVSDEwxqUWJpSUZ 8aBEGF8MTIVSDYzNtbsfVvJxMu70O/pqbpI1v6R6X/UqofkpZooL/YMXxBffeTzrhufcKQw3 H/7XkmNSzz4htfi46ba49/IcfEWt07Lvqc7mEtI+lbm5uPzOvmlLJbRvztrTqrbeo6k6+L9H cOOaG0/eam7dJ5B2/Ejk22PKk9MXcPnP+fc+wX5RYsuapPvbePqUWIozEg21mIuKEwHQeuBS bwMAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 15:14:49 -0000 Cullen et all Below is to the best of my ability my attempt to dredge up all the comments,= questions and issues you have raised on the DISPATCH list regarding draft-m= ontemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid and= our responses to address those concerns. In summary the concerns you have raised I think fall basically into 3 catego= ries: 1. Privacy - We have addressed this. The IMEI should be of no greater privacy concern t= han the UUID as an instance ID. RFC 5626 does not seem overly concerned abou= t this privacy issue as it has a very weak statement - prefer to omit is a f= ar lower strength than MUST NOT or SHOULD NOT. There is no good reason why 3= GPP should be held to a much higher standard than RFC 5626 requires but in= any case draft-allen-dispatch-imei-urn-as-instanceid and 3GPP specification= s go a lot further in protecting the Instance ID than RFC 5626 requires. 2. Interoperability - We fail to see any interoperability concerns as according to draft-allen t= he IMEI is only used as an Instance ID by 3GPP IMS compliant terminals when= registering with a 3GPP IMS network. Only 3GPP devices have an IMEI so thes= e are the only ones that can use an IMEI as an instance ID. 3GPP specificat= ions allow for devices without IMEIs to register with a UUID as an instance= ID. The IMEI is not sent end to end except when required for Emergency Call= s per regulatory requirements - i.e when the PSAP expects to receive it. RFC= 5626 anticipates that instance ID might in the future contain other URNs ot= her than a UUID so in any case a UA (e.g B2BUA) or proxy should not have a p= roblem receiving a non UUID in an Instance ID 3. IPR - Research In Motion (now known as BlackBerry) has made a declaration on thi= s draft over 3 years ago and the IPR situation and terms seems quite clear.= I think Dale explained a long time ago why this should not be a showstopper= concern. With regard to finding 3GPP specifications I think we have addressed this wi= th links provided in the references to where the 3GPP specifications are loc= ated. >From this Cullen can you please indicate what specifics we have not addresse= d in the drafts? Andrew OK HERE GOES: - A RECORD OF 4 YEARS OF EMAIL PING PONG! Cullen, Dale > From: "Cullen Jennings (fluffy)" > > But the instance ID is in a register sent to trusted providers that > know the users name, credentials etc and can be send in an encrypted > channel. This is a bit different it that it goes to other users. The > analysis is not at the same. This is a bit awkward to read, but I believe that your intention is: When the instance ID is in a REGISTER, it is sent to trusted providers that know the user's name, credentials, etc. already, and it can be sent in an encrypted channel. This proposal (i.e., draft-allen-dispatch-imei-urn-as-instanceid) is different in that the the GRUU containing the IMEI is sent to other users. The analysis is not the same. Please correct me if I'm wrong. But assuming that I'm correct: Yes, draft-allen-dispatch-imei-urn-as-instanceid results in the IMEI being sent t= o other users, embedded in the Contact GRUU. And the privacy analysis of th= at is different from that of a REGISTER. The user that receives the IMEI-containing URI does not have a database mapp= ing the IMEI to the user's name or other data. (Or at least, I don't expect= the service providers to make their database available to subscribers.) So the IMEI-containing URI is reduced from a personal identifier to a "const= ant user fingerprint", an identifier that is associated with just one person= , but anyone who wants to make use of that fact has to figure out themselves= which person it is. And that is the same as any with other GRUU. If one's phone is using a GRUU= , any conversant can record the GRUU and one's name, and use it to identify= further calls from one's self. Of course, if the user intends anonymity, the user can cause the UA to obtai= n a temporary GRUU which is not a constant user fingerprint, as is implied b= y section 8 of the draft. We've already worked through this problem. [AA] response: draft-allen addresses this. The gr parameter is generated from the IME in t= he instance ID but is not the IMEI URN: 7. 3GPP Registrar Procedures In 3GPP IMS when the Registrar receives in the Contact header field a "sip.instance" media feature tag containing the GSMA IMEI URN according to the syntax defined in draft-montemurro-gsma-imei-urn-13 [3] the registrar follows the procedures defined in RFC 5626 [1] and RFC 5627 [2] if those extensions are supported and indicated as supported by the UA. If the Registrar allocates a public GRUU according to the procedures defined in RFC 5627 [2] the instance-id MUST be obfuscated when creating the "gr" parameter in order not to reveal the IMEI to other UAs when the public GRUU is included in non- register requests. 3GPP TS 24.229 [6] subclause 5.4.7A.2 defines the mechanism for obfuscating the IMEI when creating the "gr" parameter. 3GPP TS 24.229 ] subclause 5.4.7A.2 states: If the "+sip.instance" header field parameter from the Contact address conta= ins an IMEI URN, as specified in draft-montemurro-gsma-imei-urn [153], then= the value of the "gr" SIP URI parameter is generated by the S-CSCF using th= e name-based UUID algorithm defined in RFC 4122 [154]. The following applies= to the algorithm: - the namespace shall be a UUID generated for use across the ad= ministrative domain and shall use the algorithm for creating a UUID from tru= ly random numbers specified in RFC 4122 [154]; NOTE: If the generated UUID is changed, then newly created GRUUs will not= match those that were created with the previous UUID. Therefore, the UUID n= eeds to remain the same in order to create consistent GRUUs. - SHA-1 shall be used as the hash algorithm; and - the "name" is made up of a concatenation of the TAC and SNR p= ortions of the IMEI from the "+sip.instance" header field parameter. Andrew Cullen I don't fully understand your comment maybe because there are several gramma= tical or typing errors in the first two sentences. Are you saying that in your view the instance ID being sent in a register re= quest to a cellular service provider is an issue? The IMEI is already transmitted to the cellular carriers from every GSM, UMT= S and LTE mobile phone using the existing technology and this has been the c= ase since the beginning of GSM (since about 1992). Also in CDMA the MEID (mo= bile Equipment ID) is sent to the CDMA network carriers in every CDMA networ= k. OR are you suggesting that we are sending the instance ID to other users - t= his we are NOT doing. Andrew -----Original Message----- From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] Sent: Saturday, March 02, 2013 6:34 PM To: Andrew Allen Cc: Tom Taylor; Gonzalo Camarillo; dispatch@ietf.org list Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted But the instance ID is in a register sent to trusted providers that know the= users name, credentials etc and can be send in an encrypted channel. This i= s a bit different it that it goes to other users. The analysis is not at the= same. On Jan 19, 2013, at 11:31 AM, Andrew Allen wrote: > Cullen > > To clarify these comments I think are your comments not Tom Taylor's (Tom= simply forwarded my original post as it was rejected due to attached diff f= iles). > > Where does it state in RFC 5626 or anywhere else that an instance ID can b= e changed by the user? > > In fact RFC 5626 states the opposite: > > 3.1. Summary of Mechanism > Each UA has a unique instance-id that stays t= he same for this UA even if the UA reboots or is power cycled. > > And > > 4.1. Instance ID Creation > > Each UA MUST have an Instance Identifier Unifo= rm Resource Name (URN) [RFC2141] that uniquely identifies the device. Usage= of a URN > provides a persistent and unique name for the UA instance. = It also provides an easy way to guarantee uniqueness within the AOR. This > URN MUST be persistent across power cycles of the device. > > So the instance ID is persistent (RFC 5626 wording) and does not change an= d is not changeable by the user. Whether the instance ID is a UUID or IMEI t= his does not change. > > If an Instance ID containing a UUID is provided in a SIP request or respon= se to another party then it can be stored as the instance ID of a device bel= onging to that user if their identity is known. Then if the same instance ID= is provided again in a SIP request when the originating user requests anony= mity then that user can potentially be identified by correlation with the st= ored instance ID. > > If I call you and your device rings and in the response I receive the inst= ance ID I can potentially learn the Instance ID of the specific device even= if it is a UUID. > > This is the same regardless of whether the instance ID is a UUID or IMEI.= In 3GPP usage the instance ID is never supplied to the far end party except= for the case of emergency calls where the far end is a PSAP. > > RFC 5626 does not seem overly concerned about this privacy issue as it has= a very weak statement - prefer to omit is a far lower strength than MUST NO= T or SHOULD NOT. > > The only thing it states about it is: > > 4.1. Instance ID Creation > > One case where a UA could prefer to omit the "= sip.instance" media feature tag is when it is making an anonymous request o= r some other privacy concern > requires that the UA not reveal its identity. > > 3GPP procedures and draft-allen-dispatch-imei-urn-as-instanceid protect re= velation of the Instance ID far more than is required by RFC 5626. > > Andrew > > -----Original Messsage----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beha= lf Of Cullen Jennings (fluffy) > Sent: Saturday, January 19, 2013 11:49 AM > To: Tom Taylor; Gonzalo Camarillo > Cc: dispatch@ietf.org > Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and= , draft-allen-dispatch-imei-urn-as-instanceid submitted > > > On Nov 20, 2012, at 10:16 AM, Tom Taylor wrote= : > >> Those that think privacy issues are insufficiently addressed need to expl= ain why the IMEI is of significantly greater concern in terms of revealing p= rivacy than the UUID when used as an instance ID. > > That has been explained in detail multiple times. For one thing, the user= can't change the IMEI. For a second thing, it can be directly mapped to a s= pecific user in many cases. > >> >> In our view the security concerns raised have now been sufficiently addre= ssed in the drafts and to a much higher bar than that of UUID in RFC 5626. > > I strongly disagree. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately 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. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- 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. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Cullen An IPR declaration on these drafts was made over 3 years ago so I think the= IPR situation and terms are well known. I think Dale Worley in some much earlier thread also explained why in his v= iew this should not be an issue preventing progress of the draft. I concur w= ith Dale on that. Andrew -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf= Of Cullen Jennings (fluffy) Sent: Saturday, January 19, 2013 11:50 AM To: Tom Taylor Cc: dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted I would like to point out that several of my comments, including the one abo= ut IPR, had never been addressed. On Nov 20, 2012, at 10:16 AM, Tom Taylor wrote: > Andrew's original note appeared to me at least as a brief message: "WARNIN= G: contains banned part", with attachments. As a public service, I have extr= acted and reproduced the text of his message. Hope this isn't a duplicate fr= om others' point of view. > > Tom Taylor > > Andrew's message: > =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 > New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-im= ei-urn-as-instanceid were submitted at the beginning of October. > > http://www.ietf.org/internet-drafts/draft-allen-dispatch-imei-urn-as-insta= nceid-06.txt > > http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-11.txt > > There are not many major changes since the previous versions which were su= bmitted in March and July which themselves were submitted after the conferen= ce call held between 3GPP and IETF interested parties in early January on th= e topic. Basically editorial updates and some strengthening of the normative= language. > > The main change in draft-montemurro-gsma-imei-urn since the previous versi= on is to address the ABNF comment from Dale and it was decided we do not nee= d parameters to have multiple values so Dale's proposed resolution has been= adopted. The January version of draft-montemurro-gsma-imei-urn (09 version)= added the following to the Security Considerations section to address the p= rivacy concerns: > > Further, because IMEIs can be loosely correlated to a user, they > need to be treated as any other personally identifiable > information. In particular, the IMEI SHOULD NOT be included in > messages intended to convey any level of anonymity. > > In the latest (11 version) this has been strengthened from a SHOULD NOT to= a MUST NOT. > > The draft-allen-dispatch-imei-urn-as-instanceid 05 version that was submit= ted in March incorporated a number of significant changes including: > > 1. Additional text was added to the abstract stating: > > [The purpose of the draft] is to fulfil the requirements in RFC 5626 [1] t= hat state "If a URN scheme other than UUID is used, the UA MUST only use URN= s for which an RFC (from the IETF stream) defines how the specific URN needs= to be constructed and used in the "+sip.instance" Contact header field para= meter for outbound behavior." > > 2. A new section was added describing the three 3GPP use cases > > 3. A new section was added for 3GPP Registrar Procedures with the follo= wing text: > > In 3GPP IMS when the Registrar receives in the Contact header field a "sip= .instance" media feature tag containing the GSMA IMEI URN according to the s= yntax defined in draft-montemurro-gsma-imei-urn-09[3] the registrar follows= the procedures defined in RFC 5626 [1] and RFC 5627 [2] if those extensions= are supported and indicated as supported by the UA. If the Registrar alloc= ates a public GRUU according to the procedures defined in RFC 5627 [2] the t= he instance-id MUST be obfuscated when creating the "gr" parameter in order= not to reveal the IMEI to other UAs when the public GRUU is included in non= register requests. 3GPP TS 24.229 [6] subcluase 5.4.7A.2 defines the mechan= ism for obfuscating the IMEI when creating the "gr" parameter. > > 4. The security section was beefed up as follows: > > Because IMEIs like other formats of instance IDs can be loosely correlated= to a user, they need to be treated as any other personally identifiable inf= ormation. In particular, the "sip.instance" media feature tag containing th= e GSMA IMEI URN MUST NOT be included in requests or responses intended to co= nvey any level of anonymity. RFC 5626 [1] states "One case where a UA could= prefer to omit the "sip.instance" media feature tag is when it is making an= anonymous request or some other privacy concern requires that the UA not re= veal its identity". The same concerns apply when using the GSMA IMEI URN as= an instance ID. Publication of the GSMA IMEI URN to networks that the UA i= s not attached to or the UA does not have a service relationship with is a s= ecurity breach and the "sip.instance" media feature tag MUST NOT be forwarde= d by the service provider's network elements when forwarding requests or res= ponses towards the destination UA. > > In order to protect from tampering the REGISTER requests containing the GS= MA IMEI URN MUST be sent using a security mechanism such as TLS [12] (or ano= ther security mechanism that provides equivalent levels of protection). > > There do not seem to be any comments made against the draft-allen-dispatch= -imei-urn-as-instanceid-05 version that was submitted in March. Not sure if= this was because everyone was Ok with it or because it was overlooked. > > At the conference call held between 3GPP and IETF interested participants= in January at which privacy concerns about the use of the IMEI as an instan= ce ID by 3GPP were raised. It was proposed during the conference call that t= he authors submit a new revision of the draft clarifying the use of the mech= anism and explaining how the 3GPP architecture addresses the privacy issues= that were discussed. > > There was a further discussion at a following 3GPP meeting on these privac= y concerns. During the 3GPP discussion it was pointed out that RFC 5626 alre= ady previously considered and addressed privacy concerns with instance ID i= n section 4.1 which only states the "UA could prefer to omit the "sip.instan= ce" media feature tag": > > 4.1. Instance ID Creation > Cullen To clarify these comments I think are your comments not Tom Taylor's (Tom si= mply forwarded my original post as it was rejected due to attached diff file= s). Where does it state in RFC 5626 or anywhere else that an instance ID can be= changed by the user? In fact RFC 5626 states the opposite: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays= the same for this UA even if the UA reboots or is power cycled. And 4.1. Instance ID Creation Each UA MUST have an Instance Identifier Uni= form Resource Name (URN) [RFC2141] that uniquely identifies the device. Usa= ge of a URN provides a persistent and unique name for the UA instance.= It also provides an easy way to guarantee uniqueness within the AOR. This URN MUST be persistent across power cycles of the device.= So the instance ID is persistent (RFC 5626 wording) and does not change and= is not changeable by the user. Whether the instance ID is a UUID or IMEI th= is does not change. If an Instance ID containing a UUID is provided in a SIP request or response= to another party then it can be stored as the instance ID of a device belon= ging to that user if their identity is known. Then if the same instance ID i= s provided again in a SIP request when the originating user requests anonymi= ty then that user can potentially be identified by correlation with the stor= ed instance ID. If I call you and your device rings and in the response I receive the instan= ce ID I can potentially learn the Instance ID of the specific device even if= it is a UUID. This is the same regardless of whether the instance ID is a UUID or IMEI. In= 3GPP usage the instance ID is never supplied to the far end party except fo= r the case of emergency calls where the far end is a PSAP. RFC 5626 does not seem overly concerned about this privacy issue as it has a= very weak statement - prefer to omit is a far lower strength than MUST NOT= or SHOULD NOT. The only thing it states about it is: 4.1. Instance ID Creation One case where a UA could prefer to omit the= "sip.instance" media feature tag is when it is making an anonymous request= or some other privacy concern requires that the UA not reveal its identity. 3GPP procedures and draft-allen-dispatch-imei-urn-as-instanceid protect reve= lation of the Instance ID far more than is required by RFC 5626. Andrew -----Original Messsage----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf= Of Cullen Jennings (fluffy) Sent: Saturday, January 19, 2013 11:49 AM To: Tom Taylor; Gonzalo Camarillo Cc: dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted On Nov 20, 2012, at 10:16 AM, Tom Taylor wrote: > Those that think privacy issues are insufficiently addressed need to expla= in why the IMEI is of significantly greater concern in terms of revealing pr= ivacy than the UUID when used as an instance ID. That has been explained in detail multiple times. For one thing, the user ca= n't change the IMEI. For a second thing, it can be directly mapped to a spec= ific user in many cases. > > In our view the security concerns raised have now been sufficiently addres= sed in the drafts and to a much higher bar than that of UUID in RFC 5626. I strongly disagree. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------------------------------------------------------------- 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. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Just to add to and correct some of Keith's comments. > As far as I understand, the use of the IMEI to do this (blacklisting / > whitelisting) happens on every cellphone already (be it according to > 3GPP or 3GPP standards (where the IMEI is the MEID). Should be "according to 3GPP or 3GPP2 standards" One other correction/clarification is that: According to 3GPP TS 24.229 the Instance ID is not normally placed in SIP IN= VITE requests or responses to INVITE for the purposes of telephony calls. Th= e exception to this is Emergency calls when the Instance ID containing the I= MEI is placed in the Contact header field of the SIP INVITE request. Other b= odies (such as OMA for push to talk) may have specified including the instan= ce ID in SIP INVITE request but (as specified in 3GPP specifications that if= this is included this is to be done) the Instance ID is removed by an inter= mediate server (e.g the PoC Server). Whitelist/Blacklist checking can be done based on the Instance ID containing= the IMEI being included in the SIP REGISTER request (as I have indicated in= a previous email) But basically I agree with the rest of Keith's comments Andrew > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: Monday, October 24, 2011 5:08 PM > To: Cullen Jennings; Worley, Dale R (Dale) > Cc: dispatch@ietf.org list > Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and > draft-allen- dispatch-imei-urn-as-instanceid > > Responding on the blacklisting / whitelisting issue. > > As far as I understand, the use of the IMEI to do this (blacklisting / > whitelisting) happens on every cellphone already (be it according to > 3GPP or 3GPP standards (where the IMEI is the MEID). > > The degree to which it occurs is as a result of regulatory pressure. > Essentially the prime requirement is from law enforcement agencies who > want to identify the use of stolen phones, and prevent those stolen > phones having value, and from operators who want to prevent stolen > phones incurring network costs for which they will never be > reimbursed. For the existing non-IMS cellphones you will find the IMEI > or MEID populating many messages including those that establish new calls. > > For IMS phones the same IMEI / MEID is present in messages when you > obtain the data channel, but as far as I understand operators want it > in messages that get exchanged more frequently, and that means putting > it in INVITE messages at the SIP layer. > > So in conclusion, the usage in this respect is to lessen the incidence > of someone coming up behind you, putting a knife in your ribs, and > making off with your latest model of fancy cellphone. And for non-IMS > usage its probably been doing that for the last 10 years (depending on > when operators were pressured by law enforcement agencies to implement > the EIR (the online database against which EIRs are checked). > > Yes it will stop calls. Does someone whos stolen your phone have the > right to make calls? > > As regards IMEIs, it is associated with the hardware, not the software. > The hardware manufacturer applies for them from some designated > authority ultimately supervised by a joint group of GSMA and TIA/TTA. > So you do not have the ability to craft your own. I believe the same > applies to MAC addresses. > > I believe the way it is used in 3GPP the IMEI is not visible to any > other than the end user who owns the phone and the network. I do not > believe it is seen by any other user (barring someone of course > deliberately revealing it). > > While there are various databases around that attempt to correlate > IMEI values to a particular type of phone, these have all been reverse > engineered by people plugging in the values in phones they have. You > will need a sight more privileges to find the equivalent information > from the official allocation database, and there is no intention to > make it any more public. > > Regards > > Keith > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > > On Behalf Of Cullen Jennings > > Sent: 24 October 2011 14:37 > > To: Worley, Dale R (Dale) > > Cc: dispatch@ietf.org list > > Subject: Re: [dispatch] draft-montemurro-gsma-imei-uri and > > draft-allen- dispatch-imei-urn-as-instanceid > > > > > > Dale - sent in my role as an individual contributor. (all my emails > > are > in > > my role as an individual contributor unless they are clearly signed > > as some other role) > > > > In the past I have made the mistake of listing all my concerns with > > this draft then one or two would get discussed for a bit and rest > > ignored so this time I'm going to try and stick with a few high > > level ones and some minor ones. We can try to resolve theses a bit > > then we can move on the others. Lets start with the stuff from your emai= l. > > > > Interoperability. > > > > I've asked multiple people does this happen in INVITEs or just > > REGISTERs and got mixed answers. It makes a big difference - at some > > level this is > a > > proposal to black list phones and / or part of a malware prevention > > systems. Or perhaps it is a proposal to white list phones and ones > > that don't have this won't work. You can say this going to be > > restricted to just the sets of people that want to use it but that > > is seldom how standards work out That might be true in the cases of > > if it only went > from > > a phone to the domain for it's AOR. However, if this will also be > > used > in > > INVITE cases, would it stop calls from any 3GPP phone to non 3GPP phone? > > Making sure that we did not have needless lack of interoperability > between > > classic IETF SIP and 3GPP style SIP has always been a goal. Even if > > this is only only on IMS phones, theses are now used well outside > > the mobile environment - we see them used on wireline and enterprise > > environments > so > > would there be a problem from other SIP devices to theses. Could a > > soft phone get the required IMEI identifier so it > was > > not blacklisted? Could a small vendor get them? These are all things > > I wonder. > > > > It's impossible to answer any of the above questions without knowing > > something about how this blacklisting stuff works and what this > identifier > > is used for. This leads to my first issues. I want a description of > > how this works so we can decide if there are interoperability > > problems or > not. > > I am constantly told this is important to 3GPP yet I can't find a > > 3GPP document that even has a reference to this draft or explains > > how it > works. > > So this is my most important question to you - Do you think this is > > unreasonable that we should ask how this works and if there are > > interoperability problems? If this is important to 3GPP, could they > > provide a pointer to a document that has reference to it and defines > > how it is used. > > > > On a minor notes related to references - I'm not objecting based on > > process crap around the references but it would be really really > > nice if the drafts could be updated so that the reference pointed at > > a specific document - not a vague family of documents where I have > > no idea if I am reading the right one or not. I never know what to > > read when I see 3GPP > > 24.237 but if you gave me a date and version, or even a link, it > > would > be > > easier. A reference should be something where we both know we are > reading > > the same document. I realize the 3GPP documents have some examples > > that have this identifier in them but I could not find a description > > of how > it > > worked. I'd also like to point out that in 2007 I asked for the > > pointer > to > > the document that explains the GSMA allocation policy as you will > > eventually need that for IESG approval but the link in the draft is > still > > wrong. Yes, I can figure out how to find the right one but is really > > too much to ask that someone could have fixed this. Ag ain, none of > > things in this paragraph matter to me on the big topic of how to > > proceed but it's hard to put this on top of ones priority list > when > > no one can bother to fix stuff that is clearly wrong. > > > > So let me be very clear on what I am looking for to start the > > interoperability discussion. We need to understand the specification > > for this to decide what interoperability problems there may or may not b= e. > My > > assumptions how how this works may be very wrong. Lets get the facts > > and make an informed decision. > > > > > > Privacy > > > > So what's the position of everyone that has been sending opinions of > this > > draft. Is the IMEI of my phone personal identifying information or now? > > Sort of hard to have a discussion without deciding that first. > > > > > > IPR > > > > On the topic of IPR. I think we need to sort out some of the simpler > > issues first and in the end I will probably rather have the IPR > discussion > > on the ietf list than here. To put it pretty bluntly, the IETF list > > is a more favorable environment for the arguments I will probably > > make around IPR. It always fascinates me me to see the proponents of > > this draft sending nasty grams to the chairs telling them do > > something that process wise they can't do but would effectively move > > the conversation from the dispatch list to the ietf list while at > > the same time the ADs and Chairs are trying to resolve the > > conversation in dispatch first which is typically much less > > concerned about IPR than the IETF is in general. I will note that > > Gonzalo thinks my drafts runs into the Andrews's patents but I have > > been working on the assumption that it does not as Andrew commented on i= t and did not file any IPR disclosure or notify the WG. > > > > > > On a finally note, I get the feeling that you think the chairs on > > not doing something they should. Obviously if there was anything > > that > required > > making a call where the consensus was not obvious or anything I > > would leave that type of decision to Mary. I am participating in > > this conversation as one of the individuals in the WG and would > > leave any complex judgment call to Mary. If you think there is > > something where my individual opinions are causing the chairs not to > > do the right things, please, grab a phone and call me about it and > > we will figure out a way where everyone agrees the chairs are doing > > the right thing. I'm not a > fan > > of the current passive aggressive approach. > > > > > > > > On Sep 20, 2011, at 1:51 PM, Worley, Dale R (Dale) wrote: > > > > > Given that the decision to be made in this working group is > > > whether to assign these I-Ds for further work to be done on them, > > > there are a small number of questions in play (with assorted other > > > issues to be addressed during the technical refinement of the proposal= ): > > > > > > 1. Does this proposal introduce any interoperability problems? > > > 2. Does this proposal present any privacy concerns? > > > 3. Does this proposal allow anyone to extract an unconscionable > > > "tax" (through the use of IPR)? > > > > > > Here are my assessments of these issues: > > > > > > 1. Does this proposal introduce any interoperability problems? > > > > > > I don't see what interoperability problems can result from the > > > introduction of an additional format of URN, as long as the format > > > adheres to the generic URN syntax. RFC 5626 section 4.1 makes it > > > clear that a SIP element may receive a +sip.instance value which > > > is in a URN namespace that it does not recognize, so any properly > > > constructed SIP element should be able to handle +sip.instance > > > values in namespaces that it does not have prior knowledge of. > > > > > > (Certainly, the one product/project that I have detailed knowledge > > > of has always treated +sip.instance as a string. Thereon hangs a tale= : > > > If the +sip.instance is a UUID-based URN, and if the UUID is based > > > on a MAC address, the registrar extracts the MAC address so that > > > the UA can be addressed through a special URI that encodes its MAC add= ress. > > > But it turns out that a popular make of UA formats its UUIDs > > > incorrectly, so that it was not recognized as a MAC-based UUID. > > > We've had to add special code to the registrar to recognize this > > > defective URN format!) > > > > > > 2. Does this proposal present any privacy concerns? > > > > > > There would be general privacy concerns if this or any other > > > +sip.instance value was present in dialog-forming requests or > > > responses, and so could be seen by the other end of phone calls. > > > But as far as I can tell, no UA uses +sip.instance in INVITEs; > > > +sip.instance values are presented only in REGISTER messages. > > > > > > On the other hand, generated GRUU values are given in INVITEs, and > > > the GRUU can give information about the UA's +sip.instance and the > > > AOR, even if the GRUU is generated using a secret key. However, > > > the problems resulting from this seem to be essentially the same > > > when the > > > +sip.instance is derived from an IMEI as when it is derived from a > > > +MAC > > > address. > > > > > > In regard to registrations, given that the intended scope of > > > application of the proposal is entirely within paid wireless > > > networks, there can be no privacy between the UA and its registrar. > > > > > > 3. Does this proposal allow anyone to extract an unconscionable > > > "tax" (through the use of IPR)? > > > > > > Though this proposal may be encumbered by IPR claims, the only > > > users who would be *required* to use this URN format are products > > > within the GSM/3GPP/IMS universe, and even then, only if > > > GSM/3GPP/IMS adopts this as mandatory-to-implement. Those users > > > might be subjected to an unconscionable tax, but the GSM/3GPP/IMS > > > universe has its own political/economic structure for deciding > > > what licensed technology is mandatory to implement and what > > > licensing terms are considered acceptable. It seems to me that we > > > can justly leave these questions to GSM/3GPP/IMS. > > > > > > There is some concern that the IPR disclosures were filed "late". > > > However, as the latest IPR disclosure was filed in January 2011, > > > the working group is now even later, and the objection has expired. > > > > > > In summary, I don't see any of these issues as being particularly > > > problematic. If I've overlooked an important aspect of this, I > > > would like to see some detailed information about it. > > > > > > Dale > > > _______________________________________________ > > > 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 --------------------------------------------------------------------- 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. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Cullen I think my email prior to Dale's that Dale replied to responded to all your= points Andrew ----- Original Message ----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Friday, September 16, 2011 07:21 AM To: Worley, Dale R (Dale) Cc: Mary Barnes ; dispatch@ietf.org Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-a= llen-dispatch-imei-urn-as-instanceid On Sep 15, 2011, at 9:46 AM, Worley, Dale R (Dale) wrote: > Based on responses that have been sent to my original rant, > > (1) I formally request the chairs to recognize that rough consensus > has been reached that the work described in > draft-montemurro-gsma-imei-urn and > draft-allen-dispatch-imei-urn-as-instanceid should progress, and those > proposals be dispatched to an appropriate working group. Did any the emails sent since your rant discuss any of the issues raised? Of= course no one has ever objected some organization such ad GSM having a URN= they can use. > > (2) I ask any person who believes that the current methods of > constructing SIP instance ids can be significantly improved upon > (along any dimension), and who wishes to work on improving them, > present proposals for research and/or implementation to Dispatch or > another working group, so that the state of SIP can be improved. I have. > > Dale > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Cullen Apologies for the delay in responding. With some vacation time, a 3GPP meeti= ng to prepare for and attend and being sick for the past week this is the fi= rst chance I have had to respond. Responses included below: Andrew > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, July 26, 2011 5:23 PM > To: Andrew Allen > Cc: DISPATCH list > Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen- > dispatch-imei-urn-as-instanceid > > > On May 27, 2011, at 23:07 , Andrew Allen wrote: > > > Cullen > > > > Responses to your technical points below: > > > > regards > > Andrew > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > >> On Behalf Of Cullen Jennings > >> Sent: Wednesday, May 18, 2011 1:11 PM > >> To: DISPATCH list > >> Subject: [dispatch] draft-montemurro-gsma-imei-urn anddraft-allen- > >> dispatch-imei-urn-as-instanceid > >> > >> > >> I have said in the past, I have several concerns around the > >> combined proposal in these two drafts. In this email, I've tried to > >> focus on > > the > >> high level problems and ignore small problems in the drafts that > >> can > > be > >> fixed by change a bit of text in the drat. > >> > >> The biggest issues is that this is going to reduce interoperability > > with > >> systems that don't use this type of instance id yet this does not > > provide > >> features that could not be done in away that did not reduce > >> interoperability. > > > > Can you please elaborate on what your interoperability concerns are? > > I don't see any issue with end to end interoperability since with > > public GRUU the gr parameter is opaque. Devices that contain an IMEI > > are only those devices specified by 3GPP. Only 3GPP mandates that > > the IMEI is included in the instance ID, non 3GPP devices or devices > > not operating in an IMS network do not need to use an IMEI (indeed a > > non 3PP device would not even have an IMEI to use). RFC 5626 allows > > the possibility for URNs other than UUID to be used as an instance > > ID and RFC 5627 does not mandate an algorithm for the generation of > > GRUUs based on the instance ID. If the 3GPP determines that its > > devices that already contain an IMEI for their device ID need to use > > that as an Instance ID and defines a GRUU generation algorithm that > > satisfies its requirements when receiving an Instance ID that > > contains the IMEI URN then that seems fine to me. Is your concern > > regarding a 3GPP IMS terminal registering in a non IMS domain? I > > think that in reality a device acting as an IMS terminal registering in= a non IMS compliant network isn't a practical scenario. > > There are so many 3GPP and IMS compliant things that would need to > > happen in the network for the device (acting as an IMS terminal) to > > register and obtain service that basically the network would need to > > be an IMS compliant network. Of course there is nothing preventing a > > device that is IMS capable being configured to either act as an IMS > > compliant device or a basic SIP compliant device (quite a few > > devices have such dual mode capabilities). The use of the IMEI as > > the instance ID should not in itself prevent the successful > > registration of the device in a non IMS network (since as Dale > > points out the registrar is likely to treat the instance ID opaquely if= it doesn't understand it). > > What happens in 3GPP tends to leak out into other standard and into > other systems. [AA] I don't see how this can happen as only GSM/3GPP devices can have an IM= EI (GSMA allocates the IMEI namespace). Devices that are not compliant with= the 3GPP specifications and are not part of a 3GPP system will not have an= IMEI so I don't see how it is possible for the IMEI URN to "leak out" into= other standards. > > > > >> To be concrete, let me offer an alternative solution that would be > >> interoperable, would not have any IPR that I am aware > > of, > >> and would provide the same functionality as the goals of these > >> drafts > > - or > >> at least the goals that have been stated at the IETF. > >> > >> To indicate the version of the software, I would suggest using the > >> SIP User Agent header. If a more structured form is required to > > specifically > >> line up with existing mobile systems, I would suggest defining an > >> well structured format to use inside the User Agent header field. > >> The > > advantage > >> is that this is what most sip systems do today and many management > > systems > >> already can look at this header and use it. A more structured form > > would > >> be useful by systems outside the GSMA space and would also be > > backwards > >> compatible with existing systems that treat it as an unstructured > > string. > > > > I am not against the proposal of including the software version in > > the User Agent header but don't see it as an alternative to the > > representation of the IMEI-SV as part of the IMEI URN. One of the > > main objectives of the use of the IMEI and IMEI-SV in SIP signaling > > is to maintain compatibility with the IMEI and IMEI-SV use in > > Circuit Switched signaling. In some case in circuit switched > > signaling the device will return the IMEI and in other cases the device= will return the IMEI-SV. > > It needs to be possible that devices registered in circuit switched > > domain and in the IMS domain can use whichever is returned IMEI or > > IMEI-SV in the same identifier. > > I understand both are used in circuit switched but I don't see that > that would require a design like this. > [AA] We are just trying to define a namespace to represent the IMEI and IMEI= -SV as already defined by GSMA. The latest version of draft-allen-dispatch-i= mei-urn-as-instanceid states: "The UAC SHOULD NOT include the optional "svn"= parameter in the GSMA IMEI URN in the "sip.instance" media feature tag, sin= ce the software version can change as a result of upgrades to the device fir= mware which would create a new instance ID.". 3GPP do not use the IMEI-SVN a= s an instance ID in their specifications. > >> > >> For the issue of identifying stolen handsets and correlating > >> devices between SIP and non SIP calls, I would propose that you use > >> a UUID as > > the > >> URN but that the UUID be created using IMEI or a hash of the IMEI > > instead > >> of the MAC. This would involve an extension to RFC 4122 but would > > result > >> in a system that meets the needs. Even if a hash is used, the > >> server > > side > >> can do the same hash to match. > > > > I don't fully understand the details of your proposal but a clear > > requirement is that the IMEI in the instance ID be recoverable and > > understandable by the registrar as the IMEI value of the terminal. > > Does this proposal allow the IMEI value to be obtained and > > understood by the registrar? > > The requirement was that they be matchable not recoverable which this > meets [AA] The requirement is that the IMEI be identifiable so that registration o= f barred devices (e.g stolen devices) can be prevented and also so that for= emergency calls the device used can be identified. > > > > > > If an extension to RFC 4122 is required isn't this more overhead and > > has more impact than simply defining and using a URN that represents > > the namespace that you wish to include? UUID itself is also heavier > > in computational resources and less efficient in size than the IMEI URN. > > This extension to 4122 is pretty easy and has no IPR I am aware of. > [AA] As above it seems this solution doesn't meet the above requirement that= the IMEI be recoverable. > > > >> > >> If the WG is interest in such an idea, I am glad to write up an ID > >> for each of these and submit it to the group so that it can be > >> properly considered in contrast to draft-allen-dispatch-imei-urn-as-ins= tanceid. > >> > >> As the draft-allen-dispatch-imei-urn-as-instanceid stands today, I > >> am > > not > >> in favor of publishing it as is because I believe it will result > >> in interoperability failures with the many SIP devices that don't > >> support > > it, > > > > This needs justification. 3GPP specifications also support handling > > devices that use UUID and not IMEI as many IMS compatible devices do > > not actually have an IMEI (only GSM mobile devices have an IMEI). > > I think I have provided this on more than one occasion. > [AA] As I understand from a very brief discussion with you on this in Quebec= City your concern is that GSM mobile devices may try and register using the= IMEI as an Instance ID on non IMS networks. I don't think this is a practic= al scenario. There are so many IMS specific things that 3GPP devices that co= ntain IMEIs do and expect the network to do that a device acting as a compli= ant 3GPP IMS device would not successfully register with a non 3GPP IMS comp= liant network. Firstly 3GPP IMS mobile devices that contain an IMEI either o= btain or derive their registered public user identity (which becomes the add= ress of record), the domain name to register in and their security parameter= s for authentication from the SIM card or UICC. Only GSM network operators s= upply SIM cards and UICCs that contain other GSMA allocated identities such= as mobile country code (MCC) and mobile network code (MNC) so a 3GPP IMS de= vice (with an IMEI) cannot register (according to IMS procedures) with any n= etwork that is not a network operated by a GSM operator. Additionally lower= layer security mechanisms upon which SIP signaling relies are also dependen= t on the SIM card or UICC based security mechanisms so a 3GPP IMS device (wi= th an IMEI) could not even establish the necessary security contexts. Also t= he 3GPP IMS device depends on the support and usage of certain mechanisms su= ch as Service-Route header field, P-Associated-URI header field and use of s= ecurity agreement (Security-Client, Security-Server and Security-Verify head= er fields in an IMS specific manner. Without these IMS specific procedures b= eing followed the 3GPP IMS device (with an IMEI) would not be able to succes= sfully register and establish sessions. Therefore I don't see how this is a= real issue. This concern could be addressed in draft-allen-dispatch-imei-ur= n-as-instanceid by adding a statement that an IMEI is MUST only be used as a= n Instance ID by a device registering with a 3GPP IMS network. > > > >> and it has IPR that we can easily avoid and provide the same > >> functionality. I also have issues with some of the technical > >> details > > in it > >> but theses could all be fairly easily resolved with a few back and > > forth > >> of suggested text. RIM is offering awful licensing terms for > >> something that I believe you would have to implement to be workable > >> in the bulk mobile SIP deployments. Give this is easily avoidable, > >> I think we > > should > >> avoid it. It's not really a topic for this WG but if this draft > > proceeded, > >> it was very late IPR disclosure. When it came to IETF LC, I would > >> also want to point out that the only teeth IETF has to enforce very > >> late > > IPR > >> disclosures is to say no. I'm not particularly interested in > >> talking > > about > >> this here as I don't think it will help solve the proble m but I > >> have brought this up in the past in context of this draft and > > I > >> don't want anyone to be surprised if I brought it up in an IETF LC. > >> > >> There are also significant privacy concerns around this proposal. A > > key > >> design of GRUU is being able to meet people goals of privacy while > >> not revealing private information. > > > > Privacy in GRUU is achieved through temporary GRUUs. Properties of > > temporary GRUUs are unaffected by using the IMEI as an instance ID. > > > >> The IMEI is sometimes used as a security identifier between a user > >> and SP as a shared secret. This proposal > > would > >> break theses systems. > > > > The IMEI is easily readable from the UI of mobile phones and is > > quite often printed on the case under the battery. Mobile phone > > stores sometimes keep lists (sometimes on paper) of IMEIs and the > > customers who have been allocated them (warranty reasons etc). > > agree with what you are saying but you do agree it is used as a secret > often used to show proof of possession of the phone? [AA] This is handled with the design and usage of the IMEI. The IMEI has a s= pare digit. This digit has a spare digit. This digit is always set to zero w= hen transmitted but one the mobile device has a non zero value. Thus interce= pting the transmitted IMEI value does not provide you the entire IMEI. > > > It is hardly a super > > secret security identifier. I am not aware of the security usage you > > describe and if it does exist it seems pretty flawed. > > > >> The privacy and security aspects of this would need to be addressed. > > > > 3GPP has addressed aspects of revealing the IMEI when generating > > GRUUs in their specifications. > > right, send them on over [AA] Here is the link: http://www.3gpp.org/ftp/Specs/latest/Rel-8/24_series/24229-8g0.zip > > > > >> It's conceivable that in many cases IMEI is Personal Identifiable > >> Information. > > > > IMEI is not really anymore personal information than IP address > > <..snip..> > > I'll note I think you are just wrong on this. First of all, IMEI are > more revealing than IP because they tend to be tighter bound to a > single suer instead of multiple and exist over longer time and second > of all many people, myself included, consider IP as PII in many cases. > [AA] Whether one is worse than the other is debatable but as indicated above= there isn't a issue with revealing this information since 3GPP specificatio= ns address this issue and having 3GPP IMS devices with IMEIs register on non= IMS networks isn't a practical scenario. > > > > >> The idea that every call would have to have PII information in it > >> or my call would be blocked as coming form a stolen phone seems > >> like a pretty serious flaw in this proposal. > > > > In general the IMEI is not placed in an IMS call. The blocking would > > be achieved via the registration. Blocked mobiles simply would be > > unable to register in IMS (which in IMS means they are unable to > > make calls). If an IMEI check is needed during a call the mobile can > > be requested by the network to re-register. The only use in 3GPP of > > the IMEI during an IMS call is for emergency calls. > > again, I think there are much better designs for this without IPR > issues [AA] I don't think there has been such a proposal and in any case this was t= he proposal that was agreed in 3GPP. This proposal is informational not stan= dards track and is 3GPP informing the internet community of its usage. This= is applicable for 3GPP IMS deployments only so what is the basis for these= concerns? > > > > >> I'll note I brought up the privacy issues in 2007 and have yet to > >> get > > a reply on it. > > > > > > I don't recall your previous comment (but it was 4 years ago). If we > > have failed to respond adequately to a previous comment then please > > restate it if the above responses do not cover it. > >> > >> On the topic of draft-montemurro-gsma-imei-urn, I of course think > >> it > > is > >> fine for the GSMA to be able to allocate a namespace where they > >> need > > it. > >> However, there are bunch of changes that would be needed to make > >> this draft fit all the URN rules. They are all small actionable > >> things like defining how comparison of things such as svn is > >> defined and how allocation of new things works. > > > > Of course all technical issues and concerns can be fixed. Please > > supply details on those so they can be addressed. > > > >> As I have also brought up many times in the past, what the > >> relationship between GSMA and 3GPP on this is very weird and I > >> would want clarity on that before proceeding. In the time > > we > >> have been discussing this draft, people constantly tell me that > >> GSMA > > is > >> the group that will handle the namespace allocation for the 3GPP > >> deployments yet at the same time we have approved RFC 5279 which > >> oddly looks like a better namespace for this than the GSMA one. I > >> would want > > to > >> have a clear understanding of how these different spaces interact. > >> The more we splinter this namespace, the less interoperability we have. > > > > My understanding is that in order to be allocated a URN namespace > > the registrant of the namespace has to guarantee uniqueness of the > > namespace. GSMA provides for the allocation of IMEIs and ensures > > adherence to the guidelines for IMEI allocation "GSMA Association, > > "IMEI Allocation and Approval Guidelines", PRD DG.06". Thus for the > > IMEI the GSMA is the appropriate registrant for that namespace. 3GPP > > has no responsibility for allocation of IMEIs so should not be the > > responsible registrant. 3GPP namespace would seem appropriate for > > items which are completely specified (including all their values) in > > 3GPP specifications. It should be noted that 3GPP is not a legal > > entity and might not exist for the entire period of time that IMEIs > > are being allocated and used. > >> > >> On the topic of including the software version as part of the > >> device identifier, given the software is upgraded, I think this is > >> a mistake > > and > >> it is better to consider the software version as a separate thing > >> from > > the > >> unique device identifier. It does not seem consistent with the > >> goals > > and > >> requirements of a device id URN. > > > > As stated above the software version is included for backward > > compatibility with the IMEI-SV usage in circuit switched signaling. > > The SVN is a parameter and so the original IMEI which does not > > change can be easily obtained. Registrars and other devices that > > understand the IMEI URN with the SVN parameter can ignore the > > parameter when generating GRUUs for instance. If a book has a 2nd > > edition with different content doesn't that warrant being assigned a > > new value within the ISBN URN namespace? Similarly if the software > > is upgraded the nature and capabilities of the device may change so > > doesn't this warrant a new value? Note that RFC 5626 and RFC 5627 do > > not require that the instance IDs or GRUUs be forever persistent > > (RFC 5626 only requires that it MUST be persistent through a power > > cycle). I doubt very much that most embedded SIP endpoints will > > after a complete software upgrade (such as involving completely > > rewriting flash memory) still use the same UUID as previously used eithe= r. > >> > >> I will also note that as far as process is concerned, I would > >> prefer > > the > >> problem, not the solution was brought to dispatch and we could > >> figure > > out > >> how to solve it. I do think the problem here is well worth solving, > >> I > > just > >> think there are solutions that will work better that this when > > considering > >> the whole eco systems of SIP endpoints and not just the GSM ones. > > > > When this was first proposed in 2006 all that was being done was > > registering a namespace. > > I doubt that is true. Please look at the drafts from 2006. I have > never objected to the idea that some other SDO might want a URN > namespace. If that was all that was requested, this would have been > done long ago and the current draft would not be requesting anything more= than that. > [AA] There is nothing in the early versions (around 2006) about using the IM= EI URN as an instance ID although this was added in later versions but then= removed and then specified separately in draft-allen-dispatch-imei-urn-as-i= nstanceid > > I don't think that 3GPP needs to bring requirements to the dispatch > > WG, propose a charter etc for every problem that can be solved by > > registering a namespace or a parameter. In fact the SIP change > > process has moved away from that with only specification required > > and expert review needed for defining "proprietary" SIP header > > fields. As stated above the IMEI only applies to the GSM family of > > technology mobiles not all SIP endpoints and I fail to see the > > impact of the use of the IMEI URN by the GSM family of technology > > mobiles when registering with IMS on any other SIP endpoints. This > > proposal does not mandate the use of the IMEI URN as an Instance ID > > by non 3GPP terminals and is not being proposed to become part of an > > IETF standard. This is just trying to follow the process whereby > > external users of IETF protocols register their identifiers with > > IANA and provide informational documentation to the internet > > community about such usage. It seems to me that some of the issues > > of principle being raised are those considerations that more > > appropriately apply to standards track submissions and not to these info= rmational submissions. > > > If the same > > level of consideration and debate about different solutions takes > > place for informational submissions as would take place for > > standards track submissions then I fear this will become a big > > deterrent to outside users of IETF protocol submitting their > > proprietary usages as informational RFCs for the benefit of the > > internet community and in ensuring that are no conflicts with the IANA r= egistry. > > > You are asking for something that can not be approved as an > information draft by the ISE because it impacts interoperability of > SIP devices. The bar here is somewhat higher than some information > drafts. If what you needed to be approved could be done by the ISE, I > would suggest you take it there but it can't. > [AA] As above I do not agree that there are any interoperability concerns wi= th this proposal and this is only proposed for 3GPP IMS usage of SIP not for= general internet usage. > > >> > >> Cullen in my individual contributor role > >> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > -------------------------------------------------------------------- > > - 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. > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > Cullen We had a very brief discussion regarding these drafts Friday lunchtime in Pr= ague as I had to leave Friday afternoon and so I wasn't able ti address this= point then. Basically the reason for defining a new namespace is that the URN registrant= requirements require that the registrant guarantee the uniqueness of the na= mespace. Since the GSMA and not 3GPP defines the IMEI allocation procedures= and ensures that the namespace uniquely identifies a GSM system device they= are the appropriate registrant of the namespace that represents the IMEI. Please look into the details of the latest drafts with regard to the resolut= ion of the technical comments from Paul Kyzivat and Dale Worley and the rela= ted declaration as we discussed. If we need a phone discussion on this then please let me know. Thanks Andrew ----- Original Message ----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Wednesday, March 23, 2011 06:51 PM To: Gonzalo Camarillo Cc: Mary Barnes ; Andrew Allen; Robert Sparks Subject: Re: Status of draft-montemurro-gsma-imei-urn and draft-allen-dispat= ch-imei-urn-as-instanceid 3gpp already has a URN space which they can trivial use to get URNs. I don't= think the URN has anything to with what people did not like about this. If= this was just a URN registration, no one would have any problems with it. On Mar 23, 2011, at 6:05 , Gonzalo Camarillo wrote: > Hi, > > [adding Robert to the cc:] > >> No problem with me but I am noting as Dispatch co-chair that these >> drafts clearly did not reach consensus in the dispatch WG. If the AD >> chooses to sponsor them or not is the ADs decision. > > yes, I guess that is what Andrew has in mind: to have Robert or I AD > sponsor the documents. As usual, we will only AD sponsor documents > that are not controversial. > > I agree the discussions on the DISPATCH list have not been very useful > since they did not really focus on the technical contents of the drafts. > I have just read both drafts. The process for registering a URN > namespace is described in RFC 3406, which is being revised: > > http://tools.ietf.org/html/rfc3406 > http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-00 > > In short, the apps guys would need to review the registration and we > would need to produce an RFC. So, what we need to ask DISPATCH is > whether people have technical objections to such a URN space being > created. The formal requirements for the registration will be checked > by the apps reviewers. > > Also, we would need to ask if people have any objections with mobiles > using their IMEIs as instance IDs in order to decide how to progress > the other draft. > > Cullen, Mary, could one of you ask the DISPATCH list about the issues abov= e? > > Thanks, > > Gonzalo > Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Cullen >> Am I really understanding you right that you are now saying that 3GPP >> now need to draft requirements and propose a working group charter >> simply to register a URN namespace with IANA and use that URN in a >> way already anticipated by existing RFCs? >No, of course not. If all you were doing was registering a URN you would no= t need any of this. However, >registering a URN is not really what you are= doing here, is it? As I stated on the list all these drafts do is register a URN namespace and= define its usage as an Instance ID as required by RFC 5626. What more are w= e doing than that? If 3GPP and GSMA determine that they want to use their existing device ident= ifier as an Instance ID what is the problem with that? No one seems to have= identified a technical issue with this. I fail to understand why this is co= ntroversial. Andrew -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Monday, March 21, 2011 6:30 PM To: Andrew Allen Cc: Mary Barnes; Gonzalo Camarillo Subject: Re: Status of draft-montemurro-gsma-imei-urn and draft-allen-dispat= ch-imei-urn-as-instanceid On Mar 21, 2011, at 11:17 AM, Andrew Allen wrote: > Cullen > > Am I really understanding you right that you are now saying that 3GPP > now need to draft requirements and propose a working group charter > simply to register a URN namespace with IANA and use that URN in a way > already anticipated by existing RFCs? No, of course not. If all you were doing was registering a URN you would not= need any of this. However, registering a URN is not really what you are do= ing here, is it? > > This is not the process as I understood it and is clearly not going to > happen. Ok, we can probably stop this thread now then. No worry. > > I understood that the SIP change process had in fact evolved in the > opposite direction so that IETF spends less time working on issues of > less importance to core SIP and of primary importance to other users of > SIP. With the prime focus being ensuring that identifiers (such as new > proprietary SIP headers) are appropriately documented and then > registered with IANA without requiring lots of discussion in IETF WGs. > > This position will completely undermine those of us in 3GPP who have put > our credibility on the line and fought long and hard that 3GPP and other > standards defining organizations should do things the right way by > registering identifiers used in IETF protocols with IANA and follow the > IETF process for doing that. 3GPP has recently started (unfortunately) > defining in their specifications alone some parameters that according to > the process ought also to be registered with IANA and published in RFCs > because they couldn't achieve progress on those issues in IETF. Such a > position will make such things common place as it undermines the Andrew > Allen's of the world and strengthens the position of the Martin Dolly's. > If those of us who have been friends of IETF in 3GPP cannot get the most > simple things that have no outstanding technical objections progressed > then how can we possibly advocate the position that more complex and > controversial things should be worked through IETF? Does IETF still wish > to continue to cooperate with 3GPP or not? >From everything I can see that the IETF is doing, I would say the answer is= clearly "yes", the IETF does wish to continue cooperating with 3GPP and I v= iew it has highly likely that it will continue to do so. If they can reach I= ETF consensus or not in an IETF Last Call would be interesting to watch. > > The only philosophical discussions on the list on these drafts came from > Henry who acknowledged he doesn't have technical comments. Paul and Dale > both reviewed the drafts in detail, and contributed to the technical > improvement of the drafts. All their technical comments have been > addressed to their satisfaction in the latest versions. The drafts have > received support on the dispatch list including from significant players > in the 3GPP and GSMA community as well as more primary IETF players and > are already referenced in 3GPP and GSMA specifications. > > I request (as Dale Worley recommended on the list) that these drafts be > progressed as AD sponsored drafts. I see no need for further discussion > in dispatch. No problem with me but I am noting as Dispatch co-chair that these drafts cl= early did not reach consensus in the dispatch WG. If the AD chooses to spons= or them or not is the ADs decision. > > Andrew > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, March 21, 2011 10:27 AM > To: Andrew Allen > Cc: Mary Barnes; Gonzalo Camarillo > Subject: Re: Status of draft-montemurro-gsma-imei-urn and > draft-allen-dispatch-imei-urn-as-instanceid > > > My advice would be propose some requirements of what is needed here > along with a proposed charter and bring them to dispatch. We can deal > with things like that quickly. The current thread on dispatch quickly > turned in to philosophy more than discussions of this draft or the > problem it solved. > > Cullen > > On Mar 21, 2011, at 3:14 AM, Gonzalo Camarillo wrote: > >> Cullen, Mary, >> >> could you please let Andrew (in the cc:) know how to proceed with the >> following two drafts? >> >> o draft-montemurro-gsma-imei-urn >> o draft-allen-dispatch-imei-urn-as-instanceid. >> >> There have been some discussions on the DISPATCH list in the last > weeks >> and he would like to know what the next steps are. >> >> Thanks, >> >> Gonzalo >> > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately 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. Cullen Sorry for the delay in responding due to Thanksgiving holiday last week. Currently 3GPP mobile devices all use the IMEI as their unique device identi= fier. The IMEI is the only device identifier that can be transported in 3GPP= circuit switched signaling without further enhancement of the circuit switc= hed signaling protocol. 3GPP has specified handover of calls between direct= access via IMS and indirect access via the Circuit switched domain while pr= oviding all services via servers hosted in the IMS. To do this a mobile swit= ching center server (MSC server) enhanced for ICS (IMS centralized services)= SIP registers on behalf of the IMS terminal when that terminal is attached= via the circuit switched domain. In order that the IMS terminal be reachabl= e using the same GRUU regardless of whether it is connected directly via IMS= or indirectly via the MSC server enhanced for ICS, the MSC server enhanced= for ICS needs to use the same Instance ID when it registers with the IMS as= the IMS terminal does when it registers directly with IMS. Since the only d= evice identifier that is transportable via the CS domain signaling to the MS= C server enhanced for ICS is the IMEI the Instance ID needs to contain the I= MEI of the terminal when the terminal registers directly with IMS or when th= e MSC server enhanced for ICS registers on the terminal's behalf. Additionally provision is made in 3GPP systems for checking of the IMEI (on= black lists or white lists) in order that mobiles which have for example be= en reported as stolen can be blocked from access to the systems (in some cou= ntries such as Belgium (I understand) this is a regulatory requirement and i= n some other countries such as the UK mobile operators have voluntary provid= ed this capability to address this societal concern). 3GPP TS 22.016 states: "It shall be possible to perform the IMEI check at any access attempt, excep= t IMSI detach, and during an established call at any time when a dedicated r= adio resource is available, in accordance with the security policy of the PL= MN operator. It shall also be possible to perform the IMEI check when a UE i= s IMS registered." Thus it needs to be possible to perform the IMEI check during the IMS/SIP re= gistration of the terminal. Note that IMS procedures using reg-events can al= so force an IMS terminal to re-register during a call thus allowing the IMEI= check to also be performed during an IMS call (using the same registration= procedure check). I hope this explains the underlying reasons why 3GPP has chosen to use IMEI= for the Instance ID for IMS terminals. Andrew -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf= Of Cullen Jennings Sent: Friday, November 19, 2010 10:27 AM To: DISPATCH list Subject: Re: [dispatch] Revised draftdraft-allen-dispatch-imei-urn-as-instan= ceid With my WG hat chair on ... This draft has IPR declared on it which makes me= need to ask the questions of what is this draft does that we could not do s= ome different way. So what is this draft provides that GRUU does not? On Oct 29, 2010, at 11:00 AM, Andrew Allen wrote: > A revised version of draft-allen-dispatch-imei-urn-as-instanceid was uploa= ded earlier this week and can be found at > > http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-01.txt > > Please provide any feedback. > > Thanks > Andrew Allen > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately 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. _____________________= __________________________ > 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 --------------------------------------------------------------------- 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. From pkyzivat@alum.mit.edu Tue Mar 12 09:51:22 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F6711E80D2 for ; Tue, 12 Mar 2013 09:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.062 X-Spam-Level: X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 yHWXFkjLhxwg for ; Tue, 12 Mar 2013 09:51:20 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 3199C11E80D9 for ; Tue, 12 Mar 2013 09:51:18 -0700 (PDT) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta03.emeryville.ca.mail.comcast.net with comcast id AcrY1l00417UAYkA3grDWR; Tue, 12 Mar 2013 16:51:13 +0000 Received: from dhcp-11c0.meeting.ietf.org ([IPv6:2001:df8:0:16:e4e8:37a9:96e2:16ed]) by omta13.emeryville.ca.mail.comcast.net with comcast id AgrC1l0052khnUS8ZgrCM7; Tue, 12 Mar 2013 16:51:12 +0000 Message-ID: <513F5CFF.2070608@alum.mit.edu> Date: Wed, 13 Mar 2013 00:51:11 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363107073; bh=LfCwsLrj9Pp1RQw7nl8n+5TyArLvzAvBvRf/BlaZXUE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pFYFEOmLoMM0uHrSszXQG01s+bsag3aHK9NepFh11aD/MI24IGK5nDuDV0KE/I8PO CVnzQpDx1+Aablctd91Oo8WSXTYXBhkIceLlQiim2otEcGrVYrCwud/SWxStZo20LN pvB4Dm5/DqzS+kQ5g9l/HTvzgdNEG3UAlP4YZa9eGocySN2LVs6tXiWqwib3NFNFbW rJzWPpbUaX94jtoxGrQlQtgkicjsPY9HeGYG8EpcbOSHJGBNtVQn7RwWF7f5ICPCk5 mPJ+v8L0bBm8Scz+JutHDp4bBork+oDN7Y0hDaMl/1C+TIBKuTWQycr3QfTTpay37C Gz2KHxiv7/WXw== Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:51:22 -0000 I am ok with this. *BUT* I still want to again raise the question whether we should be thinking in general about the porting of existing protocols to new transports. The RTCWEB effort is putting a lot of emphasis on rapid session startup and connection establishment. In that environment it is attractive to think about having lots of protocols run over data channels, so they can take advantage of multiplexing and quick startup. This could apply to BFCP and MSRP that are working on websocket transports. And how many more will there be? Because websockets and data channels will be similar from an API perspecitive, perhaps it would be possible to define a transport mapping that works for both. But that won't help unless both are actually implemented. Thanks, Paul On 3/12/13 10:02 PM, Mary Barnes wrote: > Hi all, > > As discussed in the DISPATCH WG session, we are doing an official call > for comments/agreement to move this work item to the BFCPbis WG. If > folks could please respond if they support this or provide comments if > you do not. > > As discussed in the meeting, if we get agreement, the chairs/ADs would > update BFCPbis WG charter to include this work item and forward to WG > and IESG for review/approval. The WG would then need to decide > whether to adopt this specific document towards that WG deliverable. > > Please respond no later than Friday, March 22nd, 2013. Silence will > be taken as agreement. > > Thanks, > Mary > DISPATCH WG co-chair > > On Thu, Feb 21, 2013 at 11:38 AM, Victor Pascual Avila > wrote: >> Hi all, >> >> We have submitted a new Internet draft to describe the WebSocket >> Protocol as a Transport for the Binary Floor Control Protocol (BFCP). >> We are looking forward to your review comments. >> >> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >> >> Best regards, >> -Victor >> >> >> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" >> wrote: >> >>> >>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt >>> has been successfully submitted by Victor Pascual and posted to the >>> IETF repository. >>> >>> Filename: draft-pascual-dispatch-bfcp-websocket >>> Revision: 00 >>> Title: The WebSocket Protocol as a Transport for the Binary Floor >>> Control Protocol (BFCP) >>> Creation date: 2013-02-15 >>> Group: Individual Submission >>> Number of pages: 9 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-websocket- >>> 00.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket >>> Htmlized: >>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>> >>> >>> Abstract: >>> The WebSocket protocol enables two-way realtime communication between >>> clients and servers. This document specifies a new WebSocket sub- >>> protocol as a reliable transport mechanism between Binary Floor >>> Control Protocol (BFCP) entities to enable usage of BFCP in new >>> scenarios. This document normatively updates >>> [I-D.draft-ietf-bfcpbis-rfc4582bis] and >>> [I-D.draft-ietf-bfcpbis-rfc4583bis] >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >> _______________________________________________ >> 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 mary.ietf.barnes@gmail.com Tue Mar 12 09:56:06 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0348811E8108 for ; Tue, 12 Mar 2013 09:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.766 X-Spam-Level: X-Spam-Status: No, score=-103.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 OPRCTRfeaQeG for ; Tue, 12 Mar 2013 09:55:46 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C03411E80FA for ; Tue, 12 Mar 2013 09:55:38 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id bv4so1713289qab.17 for ; Tue, 12 Mar 2013 09:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=f0QHjpEpqsKPEv1wx8y6aCH8KPGjbhVqoBbF4wI62ko=; b=wYUu6u7kiGpmKEETqwOtnJTlc9Fag6Ycm4c8vHCtt8UrAOnzdTzO46UA1iQmHB6B33 +biyw9+u/stteY+tD6jXHLvDu9NrZ4UGBF8oDW1P+fVdtpxlVYoGxQj4JievCFSxofDA FTi9gRXsSqf9/Xbp1tO9AgZYxOeayCChp0+gPPxldTUtzYly5KOkQ6SLgGRbsYKC8/QK REoj1+gl83hJmi9z6WFBB5WYcIpxb6vupNKzRgx6Bkord/axYIDCbL7N6K+UiDkQzSWo xXy4ZEWsnMNmFo6fX1D8wNr/RvRH6tCmNb6/0Ou6bpvu5RVYVebAw4LcoosI675oacWH yZpQ== MIME-Version: 1.0 X-Received: by 10.49.85.34 with SMTP id e2mr27257867qez.1.1363107330386; Tue, 12 Mar 2013 09:55:30 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Tue, 12 Mar 2013 09:55:30 -0700 (PDT) In-Reply-To: <513F5CFF.2070608@alum.mit.edu> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <513F5CFF.2070608@alum.mit.edu> Date: Tue, 12 Mar 2013 11:55:30 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:56:07 -0000 That's a different question and there's already a separate thread on that: http://www.ietf.org/mail-archive/web/dispatch/current/msg04609.html So, if folks can please have the general discussion under the appropriate subject that would help a lot. Mary. On Tue, Mar 12, 2013 at 11:51 AM, Paul Kyzivat wrote: > I am ok with this. > > *BUT* I still want to again raise the question whether we should be thinking > in general about the porting of existing protocols to new transports. > > The RTCWEB effort is putting a lot of emphasis on rapid session startup and > connection establishment. In that environment it is attractive to think > about having lots of protocols run over data channels, so they can take > advantage of multiplexing and quick startup. This could apply to BFCP and > MSRP that are working on websocket transports. And how many more will there > be? > > Because websockets and data channels will be similar from an API > perspecitive, perhaps it would be possible to define a transport mapping > that works for both. But that won't help unless both are actually > implemented. > > Thanks, > Paul > > > > On 3/12/13 10:02 PM, Mary Barnes wrote: >> >> Hi all, >> >> As discussed in the DISPATCH WG session, we are doing an official call >> for comments/agreement to move this work item to the BFCPbis WG. If >> folks could please respond if they support this or provide comments if >> you do not. >> >> As discussed in the meeting, if we get agreement, the chairs/ADs would >> update BFCPbis WG charter to include this work item and forward to WG >> and IESG for review/approval. The WG would then need to decide >> whether to adopt this specific document towards that WG deliverable. >> >> Please respond no later than Friday, March 22nd, 2013. Silence will >> be taken as agreement. >> >> Thanks, >> Mary >> DISPATCH WG co-chair >> >> On Thu, Feb 21, 2013 at 11:38 AM, Victor Pascual Avila >> wrote: >>> >>> Hi all, >>> >>> We have submitted a new Internet draft to describe the WebSocket >>> Protocol as a Transport for the Binary Floor Control Protocol (BFCP). >>> We are looking forward to your review comments. >>> >>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>> >>> Best regards, >>> -Victor >>> >>> >>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" >>> wrote: >>> >>>> >>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt >>>> has been successfully submitted by Victor Pascual and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-pascual-dispatch-bfcp-websocket >>>> Revision: 00 >>>> Title: The WebSocket Protocol as a Transport for the Binary >>>> Floor >>>> Control Protocol (BFCP) >>>> Creation date: 2013-02-15 >>>> Group: Individual Submission >>>> Number of pages: 9 >>>> URL: >>>> >>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp-websocket- >>>> 00.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >>>> >>>> >>>> Abstract: >>>> The WebSocket protocol enables two-way realtime communication between >>>> clients and servers. This document specifies a new WebSocket sub- >>>> protocol as a reliable transport mechanism between Binary Floor >>>> Control Protocol (BFCP) entities to enable usage of BFCP in new >>>> scenarios. This document normatively updates >>>> [I-D.draft-ietf-bfcpbis-rfc4582bis] and >>>> [I-D.draft-ietf-bfcpbis-rfc4583bis] >>>> >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> _______________________________________________ >>> 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 From worley@shell01.TheWorld.com Tue Mar 12 11:16:39 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8345311E8139 for ; Tue, 12 Mar 2013 11:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 Qld9O9BW+f2z for ; Tue, 12 Mar 2013 11:16:39 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 80F3211E8136 for ; Tue, 12 Mar 2013 11:16:37 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2CIGYMl024254 for ; Tue, 12 Mar 2013 14:16:36 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2CIGX4m290181 for ; Tue, 12 Mar 2013 13:16:34 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2CIGXJg289532; Tue, 12 Mar 2013 14:16:33 -0400 (EDT) Date: Tue, 12 Mar 2013 14:16:33 -0400 (EDT) Message-Id: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org Subject: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 18:16:39 -0000 What is the plan for moving forward with the IMEI drafts? As far as I can see, they're in fine shape. Dale From atle.monrad@ericsson.com Tue Mar 12 15:34:36 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8558E11E810D for ; Tue, 12 Mar 2013 15:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 rGQhjB2-VVq8 for ; Tue, 12 Mar 2013 15:34:35 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5E93521F878F for ; Tue, 12 Mar 2013 15:34:35 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-c5-513fad7a75bb Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1D.BE.32353.A7DAF315; Tue, 12 Mar 2013 23:34:34 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.183]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 23:34:33 +0100 From: Atle Monrad To: "Dale R. Worley" , "dispatch@ietf.org" Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQHOH03pMMCAzJYzhkOmkNSi4UyFuJiioubg Date: Tue, 12 Mar 2013 22:34:32 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C081C7E@ESESSMB203.ericsson.se> References: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> In-Reply-To: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjW7VWvtAg8k3ZCyWTlrAavHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfFo1mPmghUcFTOWCTUwvmfrYuTkkBAwkdg8 /wgzhC0mceHeeqA4F4eQwCFGiScTd7BDOEsYJfpO7WQHqWIT0JE49/MOK4gtIhAi8XlaJyNI kbBAM6PEhsMboBItjBL3/nhA2EYSP6ffZQSxWQRUJdZMWQ1kc3DwCnhLPFxjChIWErCTON+4 AayEU8BeYtvtt8wgJYwCshJzm3hBwswC4hK3nsxngjhUQGLJnvNQR4tKvHz8jxXCVpRof9rA CFGvI7Fg9yc2CFtbYtnC12D1vAKCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG9tzEzJz0 cvNNjMA4OLjlt8EOxk33xQ4xSnOwKInzhrteCBASSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA KBaUeivju4L/X62Vn08vnu3VvrTs6p0ZBnMOVvzPe2hY/ZJNdF8X/xoPQ1uuCQvuZu6/Kmqu acbxMNm+vuaHAF9zZ9zMpzKrryv+fbWroDAk6c5qjTOCB0SrDZULJrC1eBxpW3U4doOC/MLS toCiBavtRKODOmexbkut1Fz2YaJZzz+xOTuOKrEUZyQaajEXFScCAJ7mPcpRAgAA Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 22:34:36 -0000 Dale / all >From a 3GPP-perspective, I would like to see this draft being completed asa= p I would be happy if Gonzalo could look at Andrews summary provided to the l= ist today to see if he agree that the various concerns are discussed and me= t. I hope that Gonzalo can take the draft further. Thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dale R. Worley Sent: 12. mars 2013 14:17 To: dispatch@ietf.org Subject: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, dra= ft-allen-dispatch-imei-urn-as-instanceid submitted What is the plan for moving forward with the IMEI drafts? As far as I can = see, they're in fine shape. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From partha@parthasarathi.co.in Wed Mar 13 09:16:55 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1986E21F8CD8 for ; Wed, 13 Mar 2013 09:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 kxQIUUFtu++X for ; Wed, 13 Mar 2013 09:16:54 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.231]) by ietfa.amsl.com (Postfix) with ESMTP id 3D88221F8C69 for ; Wed, 13 Mar 2013 09:16:54 -0700 (PDT) Received: from userPC (unknown [122.179.30.179]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 1C48119080A4; Wed, 13 Mar 2013 16:16:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1363191413; bh=ZQEW6XuNaD4dT69bjrS6RB3Juo+xrMdWaSKCJInL8Nw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=CRLqnVBf/oc+hMCkGAAwkPh2XQRMjxavbLAoBrGwH7tAxlu+EQ56bzN5OrUbe026R DVnY3SQWG5T5XjdAcc73cG2inlwVY1wxG08Qkh383Vaak3FRTQ4Y9ra499kq6WfyKa O3VyImsD4ldq3jnxEiESBpTn17X75atJZK+vTWX8= From: "Parthasarathi R" To: "'Mary Barnes'" , "'Paul Kyzivat'" References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <513F5CFF.2070608@alum.mit.edu> In-Reply-To: Date: Wed, 13 Mar 2013 21:46:44 +0530 Message-ID: <004801ce2006$2b932800$82b97800$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4fQqn0MXz0PcKCS+G81Dvk16amRgAwk8vw Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0203.5140A675.01DA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: 'DISPATCH' Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:16:55 -0000 Mary, Hope the general discussion about data channel vs Websocket will be concluded before BFCPbis adds WG item for new transport. IMO, it is not good to recommend both data channel & WebSocket for the same protocol as the implementers will be forced implement both. Thanks Partha > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: Tuesday, March 12, 2013 10:26 PM > To: Paul Kyzivat > Cc: DISPATCH > Subject: Re: [dispatch] FW: New Version Notification for draft-pascual- > dispatch-bfcp-websocket-00.txt > > That's a different question and there's already a separate thread on > that: > http://www.ietf.org/mail-archive/web/dispatch/current/msg04609.html > > So, if folks can please have the general discussion under the > appropriate subject that would help a lot. > > Mary. > > On Tue, Mar 12, 2013 at 11:51 AM, Paul Kyzivat > wrote: > > I am ok with this. > > > > *BUT* I still want to again raise the question whether we should be > thinking > > in general about the porting of existing protocols to new transports. > > > > The RTCWEB effort is putting a lot of emphasis on rapid session > startup and > > connection establishment. In that environment it is attractive to > think > > about having lots of protocols run over data channels, so they can > take > > advantage of multiplexing and quick startup. This could apply to BFCP > and > > MSRP that are working on websocket transports. And how many more will > there > > be? > > > > Because websockets and data channels will be similar from an API > > perspecitive, perhaps it would be possible to define a transport > mapping > > that works for both. But that won't help unless both are actually > > implemented. > > > > Thanks, > > Paul > > > > > > > > On 3/12/13 10:02 PM, Mary Barnes wrote: > >> > >> Hi all, > >> > >> As discussed in the DISPATCH WG session, we are doing an official > call > >> for comments/agreement to move this work item to the BFCPbis WG. If > >> folks could please respond if they support this or provide comments > if > >> you do not. > >> > >> As discussed in the meeting, if we get agreement, the chairs/ADs > would > >> update BFCPbis WG charter to include this work item and forward to > WG > >> and IESG for review/approval. The WG would then need to decide > >> whether to adopt this specific document towards that WG deliverable. > >> > >> Please respond no later than Friday, March 22nd, 2013. Silence will > >> be taken as agreement. > >> > >> Thanks, > >> Mary > >> DISPATCH WG co-chair > >> > >> On Thu, Feb 21, 2013 at 11:38 AM, Victor Pascual Avila > >> wrote: > >>> > >>> Hi all, > >>> > >>> We have submitted a new Internet draft to describe the WebSocket > >>> Protocol as a Transport for the Binary Floor Control Protocol > (BFCP). > >>> We are looking forward to your review comments. > >>> > >>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 > >>> > >>> Best regards, > >>> -Victor > >>> > >>> > >>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" drafts@ietf.org> > >>> wrote: > >>> > >>>> > >>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt > >>>> has been successfully submitted by Victor Pascual and posted to > the > >>>> IETF repository. > >>>> > >>>> Filename: draft-pascual-dispatch-bfcp-websocket > >>>> Revision: 00 > >>>> Title: The WebSocket Protocol as a Transport for the > Binary > >>>> Floor > >>>> Control Protocol (BFCP) > >>>> Creation date: 2013-02-15 > >>>> Group: Individual Submission > >>>> Number of pages: 9 > >>>> URL: > >>>> > >>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp- > websocket- > >>>> 00.txt > >>>> Status: > >>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp- > websocket > >>>> Htmlized: > >>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket- > 00 > >>>> > >>>> > >>>> Abstract: > >>>> The WebSocket protocol enables two-way realtime communication > between > >>>> clients and servers. This document specifies a new WebSocket > sub- > >>>> protocol as a reliable transport mechanism between Binary Floor > >>>> Control Protocol (BFCP) entities to enable usage of BFCP in new > >>>> scenarios. This document normatively updates > >>>> [I-D.draft-ietf-bfcpbis-rfc4582bis] and > >>>> [I-D.draft-ietf-bfcpbis-rfc4583bis] > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> The IETF Secretariat > >>>> > >>> _______________________________________________ > >>> 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From eckelcu@cisco.com Wed Mar 13 11:00:25 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B92821F8DBC for ; Wed, 13 Mar 2013 11:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.031 X-Spam-Level: X-Spam-Status: No, score=-10.031 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 OLDgg6KhBXs2 for ; Wed, 13 Mar 2013 11:00:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DAEC021F8DA2 for ; Wed, 13 Mar 2013 11:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3814; q=dns/txt; s=iport; t=1363197624; x=1364407224; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wjoXXf0t661D384zCSAnKikdKnye3NypRiJYbTRFfgw=; b=geiVYlj2QiU7C/4/hmE5lTtWtJCTTno2TVAzNTaDf0Mqlo7xR0E3DudU 10GcuKavRNo1O3RI2214cKL/aYQuwJEiQwReL5+nMUmmpMQvkm6Usb8fD BC0bjriiUAtgNufn+zq52oPYNXvcWW2l30UJyZCsvkhhagruyktEVv+NI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFG9QFGtJV2b/2dsb2JhbABDxFGBWRZ0gioBAQEEAQEBNzQJAgwEAgEIEQQBAQEKFAkHIQYLFAgBCAIEAQ0FCAGHeQMPDLkaDYlEF4xFghcmCwcGgllhA5R2gn+KPoUZgVSBNoIo X-IronPort-AV: E=Sophos;i="4.84,838,1355097600"; d="scan'208";a="187082893" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 13 Mar 2013 18:00:23 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2DI0NLg024860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 18:00:23 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 13:00:23 -0500 From: "Charles Eckel (eckelcu)" To: Mary Barnes , DISPATCH Thread-Topic: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt Thread-Index: AQHOEFo+OAxE8MD9SkOsBe+Aorf9n5iih3kAgAF/nFA= Date: Wed, 13 Mar 2013 18:00:22 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , Richard Barnes , Victor Pascual , "rai-ads@tools.ietf.org" Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:00:25 -0000 My main concern with BFCP over WebSockets is that because BFCP is a binary = protocol, transporting over WebSockets would put implementation challenges = on the JavaScript applications. I'm not saying binary cannot be handled in = JavaScript, but my impression is that needing to do so is not desirable. Th= erefore, it may be worth considering defining a mapping of BFCP to JSON ins= tead of or in addition to BFCP over WebSockets. That said, I am not very fluent in web-speak, so please forgive me and set = me straight if what my concern is unfounded. Cheers, Charles > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: Tuesday, March 12, 2013 10:02 AM > To: DISPATCH > Cc: Cullen Jennings (fluffy); Richard Barnes; Victor Pascual; rai- > ads@tools.ietf.org > Subject: Re: [dispatch] FW: New Version Notification for draft-pascual- > dispatch-bfcp-websocket-00.txt >=20 > Hi all, >=20 > As discussed in the DISPATCH WG session, we are doing an official call > for comments/agreement to move this work item to the BFCPbis WG. If > folks could please respond if they support this or provide comments if > you do not. >=20 > As discussed in the meeting, if we get agreement, the chairs/ADs would > update BFCPbis WG charter to include this work item and forward to WG > and IESG for review/approval. The WG would then need to decide > whether to adopt this specific document towards that WG deliverable. >=20 > Please respond no later than Friday, March 22nd, 2013. Silence will > be taken as agreement. >=20 > Thanks, > Mary > DISPATCH WG co-chair >=20 > On Thu, Feb 21, 2013 at 11:38 AM, Victor Pascual Avila > wrote: > > Hi all, > > > > We have submitted a new Internet draft to describe the WebSocket > > Protocol as a Transport for the Binary Floor Control Protocol (BFCP). > > We are looking forward to your review comments. > > > > http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 > > > > Best regards, > > -Victor > > > > > > On 2/15/13 6:17 PM, "internet-drafts@ietf.org" > > wrote: > > > >> > >>A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt > >>has been successfully submitted by Victor Pascual and posted to the > >>IETF repository. > >> > >>Filename: draft-pascual-dispatch-bfcp-websocket > >>Revision: 00 > >>Title: The WebSocket Protocol as a Transport for the Binary Fl= oor > >>Control Protocol (BFCP) > >>Creation date: 2013-02-15 > >>Group: Individual Submission > >>Number of pages: 9 > >>URL: > >>http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp- > websocket- > >>00.txt > >>Status: > >>http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp-websocket > >>Htmlized: > >>http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 > >> > >> > >>Abstract: > >> The WebSocket protocol enables two-way realtime communication > between > >> clients and servers. This document specifies a new WebSocket sub- > >> protocol as a reliable transport mechanism between Binary Floor > >> Control Protocol (BFCP) entities to enable usage of BFCP in new > >> scenarios. This document normatively updates > >> [I-D.draft-ietf-bfcpbis-rfc4582bis] and > >> [I-D.draft-ietf-bfcpbis-rfc4583bis] > >> > >> > >> > >> > >> > >>The IETF Secretariat > >> > > _______________________________________________ > > 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 kevin@kpfleming.us Wed Mar 13 12:37:24 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264DE11E80A5 for ; Wed, 13 Mar 2013 12:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 2kIcNSSYap38 for ; Wed, 13 Mar 2013 12:37:22 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id A57B611E80A4 for ; Wed, 13 Mar 2013 12:37:22 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so1523795oag.15 for ; Wed, 13 Mar 2013 12:37:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=uELPIviWrhxuz4Gpx9M956UUfEso0FpWnoEG9IkKcjY=; b=KojMY2hFiedKHfE0Apl1RFXYFFPisdsgUv4UTzgKIjevH4yCD5EA4ksZus22/27n2e dtZdO+ADRvIs8RX+XqKynGkEZgBOJ7em5Q7Y0B5A4iysLWH03Atc9yGd8knfv8pbybSu qahwt3Z+E3Sw8v3NyeurSbq03TS9u1kKE1QovStgcATct+4af3SieAcpiw4lZPhjldNj heZ/GkTUpBL9SF95tednHyxLQ9KbzNQZnfGDcvm40BWuOv/85VTEpb/gHRIQ7+mE0/zF oNIj+3YEqUOYOYnSQisPd9uM+iEyVuPTm8Um2dyHjsD/tcbCyhWVydEBZSYL5/vECjn7 QQ6A== MIME-Version: 1.0 X-Received: by 10.60.27.169 with SMTP id u9mr16683569oeg.138.1363203442325; Wed, 13 Mar 2013 12:37:22 -0700 (PDT) Received: by 10.182.113.133 with HTTP; Wed, 13 Mar 2013 12:37:22 -0700 (PDT) In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> Date: Wed, 13 Mar 2013 15:37:22 -0400 Message-ID: From: Kevin Fleming To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=e89a8fb20174efcf9004d7d3889e X-Gm-Message-State: ALoCoQmKez9JvqhIhg1kCaeoZ4u6vj2RcMlCAH4lFj/45jWYZEtmSRK/mzGU3hTbLrj+n5xVyWkv Cc: "Cullen Jennings \(fluffy\)" , DISPATCH , "rai-ads@tools.ietf.org" , Richard Barnes , Victor Pascual Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:37:24 -0000 --e89a8fb20174efcf9004d7d3889e Content-Type: text/plain; charset=UTF-8 On Wed, Mar 13, 2013 at 2:00 PM, Charles Eckel (eckelcu) wrote: > My main concern with BFCP over WebSockets is that because BFCP is a binary > protocol, transporting over WebSockets would put implementation challenges > on the JavaScript applications. I'm not saying binary cannot be handled in > JavaScript, but my impression is that needing to do so is not desirable. > Therefore, it may be worth considering defining a mapping of BFCP to JSON > instead of or in addition to BFCP over WebSockets. > That said, I am not very fluent in web-speak, so please forgive me and set > me straight if what my concern is unfounded. > > Unlike WebRTC, Websocket is not JavaScript-specific (or even JavaScript-oriented). It's general purpose, and supports binary message transport. There are certainly applications envisionable for using WebSockets to transport protocols between a client that is *not* a browser and a server. --e89a8fb20174efcf9004d7d3889e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 13, 2013 at 2:00 PM, Charles Eckel (eckelcu) = <eckelcu@cisco.co= m> wrote:
My main concern with BFCP over WebSockets is that because BFCP is a binary = protocol, transporting over WebSockets would put implementation challenges = on the JavaScript applications. I'm not saying binary cannot be handled= in JavaScript, but my impression is that needing to do so is not desirable= . Therefore, it may be worth considering defining a mapping of BFCP to JSON= instead of or in addition to BFCP over WebSockets.
That said, I am not very fluent in web-speak, so please forgive me and set = me straight if what my concern is unfounded.


<= /div>
Unlike WebRTC, Websocket is not JavaScript-specific (or even Java= Script-oriented). It's general purpose, and supports binary message tra= nsport. There are certainly applications envisionable for using WebSockets = to transport protocols between a client that is *not* a browser and a serve= r.

--e89a8fb20174efcf9004d7d3889e-- From mary.ietf.barnes@gmail.com Wed Mar 13 12:50:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193E121F8667 for ; Wed, 13 Mar 2013 12:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.746 X-Spam-Level: X-Spam-Status: No, score=-103.746 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 eIu0FDI7HZ5z for ; Wed, 13 Mar 2013 12:50:09 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id BCF2B21F8DC9 for ; Wed, 13 Mar 2013 12:50:07 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id 6so852257qeb.0 for ; Wed, 13 Mar 2013 12:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ATdo19FRJjDI8UC34AfHMJznp7p+XG6LZ+6rFuYLYLo=; b=mEERzgel1JxPvuIMetaDAsoORDCuAkOQLs2ltmgihiNwT8oUXpAryEJLMF9n5QLF0e cwBaxvTPg9Q9nLZCWbo0TT7Nke0YLYZpWmtdKsgAGYoToNAIldUBUV7sIIbqD2Hr4dSg fvuefOLAfCGh4wAKmYcUa3+CAsFFEH+7rJUmlmrG/4Pm5nAUuByB0SU95LudBNY3AdqQ DbaePVw1qy6ETYaqjlLmXaL/Zedp3jfEf+Vb7jcNajeQgATta+7H9AxUwTjUKdfr7wqn iYrZuu72iHTH/jd+0D6Ta53DfcNFgdVJVW29wroPk8Lf0dZK2VtJyP6kKqPdK1zRWFY8 UzKw== MIME-Version: 1.0 X-Received: by 10.49.85.34 with SMTP id e2mr34938205qez.1.1363204207221; Wed, 13 Mar 2013 12:50:07 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Wed, 13 Mar 2013 12:50:06 -0700 (PDT) In-Reply-To: <004801ce2006$2b932800$82b97800$@co.in> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <513F5CFF.2070608@alum.mit.edu> <004801ce2006$2b932800$82b97800$@co.in> Date: Wed, 13 Mar 2013 14:50:06 -0500 Message-ID: From: Mary Barnes To: Parthasarathi R Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:50:10 -0000 On Wed, Mar 13, 2013 at 11:16 AM, Parthasarathi R wrote: > Mary, > > Hope the general discussion about data channel vs Websocket will be > concluded before BFCPbis adds WG item for new transport. [MB] I don't think that will necessarily happen. [/MB] > > IMO, it is not good to recommend both data channel & WebSocket for > the same protocol as the implementers will be forced implement both. [MB] We already have BFCP over TCP and UDP is currently being specified. There has not yet been a concrete proposal for BFCP over a data channel that is being defined for WebRTC. That might happen and we can discuss that when it does. [/MB] > > Thanks > Partha > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Mary Barnes >> Sent: Tuesday, March 12, 2013 10:26 PM >> To: Paul Kyzivat >> Cc: DISPATCH >> Subject: Re: [dispatch] FW: New Version Notification for draft-pascual- >> dispatch-bfcp-websocket-00.txt >> >> That's a different question and there's already a separate thread on >> that: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg04609.html >> >> So, if folks can please have the general discussion under the >> appropriate subject that would help a lot. >> >> Mary. >> >> On Tue, Mar 12, 2013 at 11:51 AM, Paul Kyzivat >> wrote: >> > I am ok with this. >> > >> > *BUT* I still want to again raise the question whether we should be >> thinking >> > in general about the porting of existing protocols to new transports. >> > >> > The RTCWEB effort is putting a lot of emphasis on rapid session >> startup and >> > connection establishment. In that environment it is attractive to >> think >> > about having lots of protocols run over data channels, so they can >> take >> > advantage of multiplexing and quick startup. This could apply to BFCP >> and >> > MSRP that are working on websocket transports. And how many more will >> there >> > be? >> > >> > Because websockets and data channels will be similar from an API >> > perspecitive, perhaps it would be possible to define a transport >> mapping >> > that works for both. But that won't help unless both are actually >> > implemented. >> > >> > Thanks, >> > Paul >> > >> > >> > >> > On 3/12/13 10:02 PM, Mary Barnes wrote: >> >> >> >> Hi all, >> >> >> >> As discussed in the DISPATCH WG session, we are doing an official >> call >> >> for comments/agreement to move this work item to the BFCPbis WG. If >> >> folks could please respond if they support this or provide comments >> if >> >> you do not. >> >> >> >> As discussed in the meeting, if we get agreement, the chairs/ADs >> would >> >> update BFCPbis WG charter to include this work item and forward to >> WG >> >> and IESG for review/approval. The WG would then need to decide >> >> whether to adopt this specific document towards that WG deliverable. >> >> >> >> Please respond no later than Friday, March 22nd, 2013. Silence will >> >> be taken as agreement. >> >> >> >> Thanks, >> >> Mary >> >> DISPATCH WG co-chair >> >> >> >> On Thu, Feb 21, 2013 at 11:38 AM, Victor Pascual Avila >> >> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> We have submitted a new Internet draft to describe the WebSocket >> >>> Protocol as a Transport for the Binary Floor Control Protocol >> (BFCP). >> >>> We are looking forward to your review comments. >> >>> >> >>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket-00 >> >>> >> >>> Best regards, >> >>> -Victor >> >>> >> >>> >> >>> On 2/15/13 6:17 PM, "internet-drafts@ietf.org" > drafts@ietf.org> >> >>> wrote: >> >>> >> >>>> >> >>>> A new version of I-D, draft-pascual-dispatch-bfcp-websocket-00.txt >> >>>> has been successfully submitted by Victor Pascual and posted to >> the >> >>>> IETF repository. >> >>>> >> >>>> Filename: draft-pascual-dispatch-bfcp-websocket >> >>>> Revision: 00 >> >>>> Title: The WebSocket Protocol as a Transport for the >> Binary >> >>>> Floor >> >>>> Control Protocol (BFCP) >> >>>> Creation date: 2013-02-15 >> >>>> Group: Individual Submission >> >>>> Number of pages: 9 >> >>>> URL: >> >>>> >> >>>> http://www.ietf.org/internet-drafts/draft-pascual-dispatch-bfcp- >> websocket- >> >>>> 00.txt >> >>>> Status: >> >>>> http://datatracker.ietf.org/doc/draft-pascual-dispatch-bfcp- >> websocket >> >>>> Htmlized: >> >>>> http://tools.ietf.org/html/draft-pascual-dispatch-bfcp-websocket- >> 00 >> >>>> >> >>>> >> >>>> Abstract: >> >>>> The WebSocket protocol enables two-way realtime communication >> between >> >>>> clients and servers. This document specifies a new WebSocket >> sub- >> >>>> protocol as a reliable transport mechanism between Binary Floor >> >>>> Control Protocol (BFCP) entities to enable usage of BFCP in new >> >>>> scenarios. This document normatively updates >> >>>> [I-D.draft-ietf-bfcpbis-rfc4582bis] and >> >>>> [I-D.draft-ietf-bfcpbis-rfc4583bis] >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> The IETF Secretariat >> >>>> >> >>> _______________________________________________ >> >>> 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 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@alum.mit.edu Wed Mar 13 20:12:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D2A21F874D for ; Wed, 13 Mar 2013 20:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 HSbbxVYDDV8r for ; Wed, 13 Mar 2013 20:12:53 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 6671321F8651 for ; Wed, 13 Mar 2013 20:12:51 -0700 (PDT) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta12.emeryville.ca.mail.comcast.net with comcast id BEYE1l00B0QkzPwACFCrn6; Thu, 14 Mar 2013 03:12:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2001:df8:0:128:2006:56e9:cf8b:4ea7]) by omta02.emeryville.ca.mail.comcast.net with comcast id BFCq1l00Q2CH3Z58NFCrKe; Thu, 14 Mar 2013 03:12:51 +0000 Message-ID: <51414032.3060902@alum.mit.edu> Date: Thu, 14 Mar 2013 11:12:50 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363230771; bh=+DMSw4h10Og6/j46tVvDqhTmVer5diCyU+2NLdpGveA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=srRIhSO8vPVwypGm07qswqTubVh1QmjZ9fLROqiU3nX4YsnnHAJCqzGkJQzOs+XLA nt33mloUlLAs0yVOQtAIy9Y/2UuiOZCiZFmQm3tiJIWOmvn/UfSS3utvC+e3BLS+ga 1bjHguDeba6gUFy9aSIGcQwmwT0sGDQC+R9flBRyjFFuPQ01x0Ia6qf2udWCRV3MpI 7SSV4D/XqTalxXTYFmA/OtMQ5DtFvUxt/J04xa7iTctU5ab+cwWgI4RyYm0H8aVhAM HMR2cHFz5xpQVd2rTD33YssnvlmrgF+wN8Ac+Ygnp3wT5Kspy3kklvHlQ2HFIZddOR 0NicO1sMCXu/w== Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 03:12:54 -0000 On 3/14/13 3:37 AM, Kevin Fleming wrote: > On Wed, Mar 13, 2013 at 2:00 PM, Charles Eckel (eckelcu) > > wrote: > > My main concern with BFCP over WebSockets is that because BFCP is a > binary protocol, transporting over WebSockets would put > implementation challenges on the JavaScript applications. I'm not > saying binary cannot be handled in JavaScript, but my impression is > that needing to do so is not desirable. Therefore, it may be worth > considering defining a mapping of BFCP to JSON instead of or in > addition to BFCP over WebSockets. > That said, I am not very fluent in web-speak, so please forgive me > and set me straight if what my concern is unfounded. > > > Unlike WebRTC, Websocket is not JavaScript-specific (or even > JavaScript-oriented). It's general purpose, and supports binary message > transport. There are certainly applications envisionable for using > WebSockets to transport protocols between a client that is *not* a > browser and a server. But there is reason to think that a browser *would* want to use BFCP, so one would think that when defining a new binding that *could* be used from a browser it would make sense to ensure that it really could. But I don't have javascript skills. I have heard variously that doing such a binary protocol in javascript would be impossible, or just inconvenient. If it is just inconvenient, then a suitable library on top could fix that. Thanks, Paul From pkyzivat@alum.mit.edu Thu Mar 14 04:58:52 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A9821F8D07 for ; Thu, 14 Mar 2013 04:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.162 X-Spam-Level: ** X-Spam-Status: No, score=2.162 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 m7f7R63FXimN for ; Thu, 14 Mar 2013 04:58:51 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8EA21F8AD8 for ; Thu, 14 Mar 2013 04:58:47 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta12.emeryville.ca.mail.comcast.net with comcast id BPxx1l0041u4NiLACPynNm; Thu, 14 Mar 2013 11:58:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2001:df8:0:128:2006:56e9:cf8b:4ea7]) by omta21.emeryville.ca.mail.comcast.net with comcast id BPym1l00D2CH3Z58hPymeg; Thu, 14 Mar 2013 11:58:47 +0000 Message-ID: <5141BB76.7080200@alum.mit.edu> Date: Thu, 14 Mar 2013 19:58:46 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: dispatch@ietf.org References: <462D69106F82344E95BC83996D8039D259FCE5F4@ASHBDAG1M1.resource.ds.bah.com> In-Reply-To: <462D69106F82344E95BC83996D8039D259FCE5F4@ASHBDAG1M1.resource.ds.bah.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363262327; bh=lscU5/fGzkBgNI13ni7YIJoIFpZRBuROqHOL+QrMp8A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pd0UY5uZG3Zq5nFSMFhKTb31OHiCtzAhSUs6hWscW45UwREhjrOLYK0lciX7va53/ fKzL5ITzLYgJeGeFnkNnW1FxDsUUF/Q03exZtiQ3nj44lAKWBQoNAHA8+r4AyzrHQg JMdYY+vxJMmEPTadqRp7RGTGoBeYeAQ8sJC3fe6LukmofVLNw4R+ya/x0sfs7U98pp 2R4oD5ia7AalwqS6eOPeZruG/a+MIX7b5yfUYzYlMOyfneKPtKKVXFZ9QKmTGxr6Bn TBUNfk0feO5bc0selCCEWHF+Wez1tvpllyl2aBaD7zQeX48jSFWrhGeKrmPHFdDvru Q1n4I1GDfqdTg== Subject: Re: [dispatch] Fwd: I-D Action: draft-christou-sip-xmpp-interop-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 11:58:52 -0000 Hi, I think this document is good as an overview. I have another case for you - a variant of both 2.2 and 2.3: User Brings own Client(s): each user is free to bring his own client, with some constraints over which clients will work at all, or will provide an acceptable user experience. Here the guidance is mostly intended for the developers of "open" clients. Thanks, Paul On 3/12/13 10:05 AM, Christou, Christos [USA] wrote: > All, > > We have submitted a draft that describes the different types of SIP to XMPP interoperability use cases. It primarily serves as an overview type of document to define the different SIP and XMPP use cases that might exist among Service Providers and implementers. In addition, it points to other documents (e.g., CUSAX, SIP-XMPP interworking documents) where the relevant interworking functions are defined. > > Please provide any feedback for this document, especially as we continue to finalize the SIP-XMPP Interworking and CUSAX docs. > > > > -------- Original Message -------- > Subject: I-D Action: draft-christou-sip-xmpp-interop-00.txt > Date: Sun, 10 Mar 2013 18:50:12 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Interoperability between the Session Initiation > Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) > Author(s) : Chris Christou > Michael Lundberg > Christopher Ross > Peter Saint-Andre > Filename : draft-christou-sip-xmpp-interop-00.txt > Pages : 7 > Date : 2013-03-10 > > Abstract: > This document is intended to serve as a reference point for > developers and operators implementing the Session Initiation Protocol > (SIP) and the Extensible Messaging and Presence Protocol (XMPP) > within their networks. This document does not define any new > protocols but does define the different reference models for > deployment of combined use of SIP and XMPP ("CUSAX") clients and SIP- > XMPP interworking to ensure consistency across the community. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-christou-sip-xmpp-interop > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-christou-sip-xmpp-interop-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From ibc@aliax.net Thu Mar 14 07:31:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9825111E811F for ; Thu, 14 Mar 2013 07:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 KYz78iX43kfi for ; Thu, 14 Mar 2013 07:31:42 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE1311E817D for ; Thu, 14 Mar 2013 07:31:21 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id j8so2849354qah.6 for ; Thu, 14 Mar 2013 07:31:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=PGwhNAyoJaWqZujG9qKMaoA/6VyGpZqK80KxTy/ackA=; b=WjBx0ze9Z+ynTswMMqEuPDfl7WUVMfbccV4d0p0lbugMbIaW2a+2AG2as6IYyDneZO 4BRp84ivIOFlmYLMwwROic4QhoDMZZVsgul8ZDKvqxvfZDhnRTwxPKWd4aOzdKxj47dO ANmec5o4vt4Nr7OKwdFy8s/+yoy7F8A/CeCOPqhOGjeD1w29d8akxq3ebl3Es9Vw0thd fk+ANMvc3qBg5RJjTIeuNjAYRbRvnthKojQRT6ZAhnz/M7SYg5dV/Da9jmudlE9NbfSM mWKv4/QOk8Q1u0y977G79xKFruicOTMA/uUuK5LLU1gBQyAd1I6UE6Hb05HV8YiOA0ui vqWw== X-Received: by 10.224.181.69 with SMTP id bx5mr3290017qab.95.1363271476142; Thu, 14 Mar 2013 07:31:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.105.166 with HTTP; Thu, 14 Mar 2013 07:30:56 -0700 (PDT) In-Reply-To: <51414032.3060902@alum.mit.edu> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 14 Mar 2013 15:30:56 +0100 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnFh7QvgoQ2usnnJpkZKUnPy9CdmHQSndiGaw6MCiDZhc4p/svthqTahWqDQxeC48GcB5vg Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:31:42 -0000 2013/3/14 Paul Kyzivat : > But I don't have javascript skills. I have heard variously that doing suc= h a > binary protocol in javascript would be impossible, or just inconvenient. = If > it is just inconvenient, then a suitable library on top could fix that. I don't think so. The "issue" here is that JavaScript cannot properly deal with binary information. This is, JS cannot get each "byte" of a received string. Maybe there are some workarounds but, for sure, it finally becomes painful. Another JS library on top of the JS BPFC stack would not help a lot. --=20 I=C3=B1aki Baz Castillo From georg.mayer.huawei@gmx.com Fri Mar 15 08:03:40 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F58F21F8566 for ; Fri, 15 Mar 2013 08:03:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYiVovsKXXlB for ; Fri, 15 Mar 2013 08:03:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 89D4821F8548 for ; Fri, 15 Mar 2013 08:03:38 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M8LTo-1Uc9rB2jHG-00w1E4 for ; Fri, 15 Mar 2013 16:03:35 +0100 Received: (qmail invoked by alias); 15 Mar 2013 15:03:35 -0000 Received: from chello062178012102.5.11.vie.surfer.at (EHLO Kurt) [62.178.12.102] by mail.gmx.net (mp019) with SMTP; 15 Mar 2013 16:03:35 +0100 X-Authenticated: #123904570 X-Provags-ID: V01U2FsdGVkX1+K2+wqEhaKc9i57FECu2OzuN0AEsHAH+YbyVwln3 KWneQODL4CZ9s4 From: "Georg Mayer" To: "'Atle Monrad'" , "'Dale R. Worley'" , References: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> <7D2F7D7ADBA812449F25F4A69922881C081C7E@ESESSMB203.ericsson.se> In-Reply-To: <7D2F7D7ADBA812449F25F4A69922881C081C7E@ESESSMB203.ericsson.se> Date: Fri, 15 Mar 2013 16:03:31 +0100 Message-ID: <001c01ce218e$444ad2b0$cce07810$@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGZmXhCHwixlArchpjazxQI+Ovj6wGanlphmQMUQiA= Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 15:03:40 -0000 Hello, I fully support these drafts going forward now. It would be great seeing them completed within short time. After Andrews clarifications I do not = see any reason to hold them back any longer. Thanks, Georg=20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Atle Monrad Gesendet: Dienstag, 12. M=E4rz 2013 23:35 An: Dale R. Worley; dispatch@ietf.org Betreff: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn = and, draft-allen-dispatch-imei-urn-as-instanceid submitted Dale / all >From a 3GPP-perspective, I would like to see this draft being completed = asap I would be happy if Gonzalo could look at Andrews summary provided to = the list today to see if he agree that the various concerns are discussed = and met. I hope that Gonzalo can take the draft further. Thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management Ericsson -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Dale R. Worley Sent: 12. mars 2013 14:17 To: dispatch@ietf.org Subject: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted What is the plan for moving forward with the IMEI drafts? As far as I = can see, they're in fine shape. Dale _______________________________________________ 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 mary.ietf.barnes@gmail.com Tue Mar 19 11:51:54 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0A321F853E for ; Tue, 19 Mar 2013 11:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 yuR64qdWhabg for ; Tue, 19 Mar 2013 11:51:54 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC95021F8536 for ; Tue, 19 Mar 2013 11:51:53 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id x7so538014qeu.3 for ; Tue, 19 Mar 2013 11:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=/CDU2s7DAClBiLIW17ri5kX/lxFG9UdsiYB/3rwHFkE=; b=xKlH7Bt/ahX8GbJulv6rch0CEYVO6ff9wy4I2d9LmPa0D0ShmMmhQrlZA6XpXqVWaq X2rD2xMN2JHh/xxkLgp7MMSypXnwF/DhKX+vGZ5GZrzUYKc62zPlznbTzI3pu5rz8BM2 ZSE+m9wPKA1j/upv0BFoypu+tjaIhbfmqZL9W3lNRE+VvEVQ5v9dtsXB2VSnVLlVroBn m4JP/bM9uzGV26wjL25CLTe/z3TWVTt2pJw/5ySSeagadOKiY7oZUMIhuyXnNV5SydbJ UDoha1UTs3v7vuhYKe+ycHG+3Y1UPBRwLZHpRF2BdYVNpsJBTM/7M0qOM7O9yRz6+N8l S1Sg== MIME-Version: 1.0 X-Received: by 10.49.87.40 with SMTP id u8mr3398213qez.62.1363719113180; Tue, 19 Mar 2013 11:51:53 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Tue, 19 Mar 2013 11:51:53 -0700 (PDT) Date: Tue, 19 Mar 2013 13:51:53 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , "rai-ads@tools.ietf.org" Subject: [dispatch] DISPATCH @IETF-86 and Plans for IETF-87 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 18:51:54 -0000 Hi all, The wiki has been updated with the documents and status as of IETF-86: http://trac.tools.ietf.org/wg/dispatch/trac/wiki/WikiStart And, the minutes were posted last week: http://trac.tools.ietf.org/wg/dispatch/minutes Please note that the IETF-87 deadlines have been set in the wiki based on the IETF-87 Important Meeting Dates: http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87 Regards, Mary From mary.ietf.barnes@gmail.com Tue Mar 19 11:57:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6E221F8F19; Tue, 19 Mar 2013 11:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.408 X-Spam-Level: X-Spam-Status: No, score=-103.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 xCZTeZwlHlXz; Tue, 19 Mar 2013 11:57:41 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id B31FC21F8CEB; Tue, 19 Mar 2013 11:57:41 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id o13so2596778qaj.5 for ; Tue, 19 Mar 2013 11:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=sTv54vllzxJUbDZibB220IacNarW5DxEPcCcUT7GBXE=; b=jZONWfwVwTNRUThl8Z5fNKnFP9j/UksV0e4QvrDh41+CAfJYpObkIZFHUVZ0hCcrnA ROe0VqteZVzg4ULotSnqDUzYOm1gI/IZYZOkinL6EEXX0tRzBBBlzXBxLpsuReM8E5iZ 2YwfGOb2ti9/Wtz0bXc/2w7B//5JVqiNuAdeVpaH9Klvzt9RAs0T14yoDnxLuOfpiFWj 2j1DCihdHSbPOVfC7wc/n8sWhWEn8xfX+khU2OQo9IVNZ5OpqgVHLVzvnynEN7+kSVN0 FsyVqjmDXhdjHywAl9BfeCXjjKq/X6p4HJIwOgbhgdKspnxFSlTmsxJQLJMvG/bUoonO MSOQ== MIME-Version: 1.0 X-Received: by 10.49.116.235 with SMTP id jz11mr2094765qeb.39.1363719460989; Tue, 19 Mar 2013 11:57:40 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Tue, 19 Mar 2013 11:57:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Mar 2013 13:57:40 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" , DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] Fwd: Call for nominations: FCC CSRIC IV X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 18:57:42 -0000 This might be of interest to some folks. Mary. ---------- Forwarded message ---------- From: Henning Schulzrinne Date: Tue, Mar 19, 2013 at 1:50 PM Subject: Call for nominations: FCC CSRIC IV To: "tccc@lists.cs.columbia.edu" , "ietf@ietf.org" Please see http://www.fcc.gov/document/fcc-extends-nominations-deadline-csric-april-12-2013 The duties of the Council will be to make recommendations to the FCC regarding actions it can take to promote communications security, reliability, and resiliency. The duties of the Council may include: a. Developing and recommending to the FCC best practices and actions it can take that promote reliable communications services, including 911, Enhanced 911, and Next Generation 911 service. b. Developing and recommending to the FCC best practices and actions it can take to improve the security of networks and mobile devices. c. Identifying and recommending to the FCC a set of best practices to make communications networks, including broadband networks and Voice over Internet Protocol (VoIP) systems, more secure and resilient. d. Developing recommendations for actions the FCC should take to enhance the ability of the public to receive timely and accurate emergency alerts and warnings, including ways to leverage advanced communications technologies and the Internet, including broadband technologies and social media platforms. e. Make recommendations with respect to such additional topics as the FCC may specify. From peter.leis@nsn.com Wed Mar 20 00:16:02 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E7D11E80A3 for ; Wed, 20 Mar 2013 00:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 TzK-tsa1zFGT for ; Wed, 20 Mar 2013 00:15:49 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 77B9021F8970 for ; Wed, 20 Mar 2013 00:15:49 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r2K7FjFl009732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Mar 2013 08:15:45 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r2K7Fhv8012495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 20 Mar 2013 08:15:43 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 20 Mar 2013 08:15:42 +0100 Received: from DEMUMBX003.nsn-intra.net ([169.254.2.239]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.02.0328.009; Wed, 20 Mar 2013 08:15:42 +0100 From: "Leis, Peter (NSN - DE/Munich)" To: "dispatch@ietf.org" Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQGZmXhCHwixlArchpjazxQI+Ovj6wGanlphmQMUQiCAB1kwQA== Date: Wed, 20 Mar 2013 07:15:42 +0000 Message-ID: <059F3547244B7F4DB728757635C2DC4B032DA1@DEMUMBX003.nsn-intra.net> References: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> <7D2F7D7ADBA812449F25F4A69922881C081C7E@ESESSMB203.ericsson.se> <001c01ce218e$444ad2b0$cce07810$@gmx.com> In-Reply-To: <001c01ce218e$444ad2b0$cce07810$@gmx.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.107] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2297 X-purgate-ID: 151667::1363763745-000053F1-CEAE85CB/0-0/0-0 Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 07:16:02 -0000 +1 Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Georg Mayer Sent: Friday, March 15, 2013 4:04 PM To: 'Atle Monrad'; 'Dale R. Worley'; dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted Hello, I fully support these drafts going forward now. It would be great seeing them completed within short time. After Andrews clarifications I do not see any reason to hold them back any longer. Thanks, Georg=20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftra= g von Atle Monrad Gesendet: Dienstag, 12. M=E4rz 2013 23:35 An: Dale R. Worley; dispatch@ietf.org Betreff: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Dale / all >From a 3GPP-perspective, I would like to see this draft being completed asa= p I would be happy if Gonzalo could look at Andrews summary provided to the list today to see if he agree that the various concerns are discussed and met. I hope that Gonzalo can take the draft further. Thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management Ericsson -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dale R. Worley Sent: 12. mars 2013 14:17 To: dispatch@ietf.org Subject: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted What is the plan for moving forward with the IMEI drafts? As far as I can see, they're in fine shape. Dale _______________________________________________ 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 From christer.holmberg@ericsson.com Wed Mar 20 00:21:24 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71F011E80A3 for ; Wed, 20 Mar 2013 00:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 H9Qwe3SbWjbK for ; Wed, 20 Mar 2013 00:21:24 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A93A721F8B04 for ; Wed, 20 Mar 2013 00:21:23 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-e8-51496372b2f9 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 54.5C.19728.27369415; Wed, 20 Mar 2013 08:21:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 08:21:21 +0100 From: Christer Holmberg To: "Leis, Peter (NSN - DE/Munich)" , "dispatch@ietf.org" Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQHOIY5J/OFUELNcWki0JUl0lcjxwZiuIZYAgAASBCA= Date: Wed, 20 Mar 2013 07:21:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B12D5C0@ESESSMB209.ericsson.se> References: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> <7D2F7D7ADBA812449F25F4A69922881C081C7E@ESESSMB203.ericsson.se> <001c01ce218e$444ad2b0$cce07810$@gmx.com> <059F3547244B7F4DB728757635C2DC4B032DA1@DEMUMBX003.nsn-intra.net> In-Reply-To: <059F3547244B7F4DB728757635C2DC4B032DA1@DEMUMBX003.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+JvjW5RsmegwdlmBYulkxawWiw7v43Z gcljyZKfTB4/119lD2CK4rJJSc3JLEst0rdL4MpomxZQcF2sYvHbo2wNjAuEuxg5OSQETCSu PelhgbDFJC7cW8/WxcjFISRwiFFiz8LzTBDOYkaJD+fuMHYxcnCwCVhIdP/TBmkQEUiWuLVr DzNIjbBAM6PEpf6rYN0iAi2MEi/aF7FCVFlJ9O+6CLaCRUBV4sCS94wgNq+At8T2MzOh1n1g lDi67g5YEaeAn8TyAxPYQGxGoJu+n1rDBGIzC4hL3HoynwniVgGJJXvOM0PYohIvH/9jhbAV Ja5OXw5VrydxY+oUNghbW2LZwtfMEIsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWM7LmJ mTnp5UabGIHxcHDLb9UdjHfOiRxilOZgURLnDXe9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmD U6qBMT1V6/DOWCGm5RPr6ifNfVrerbPliPOBhbd9OrXu7f+xPztdas7vez+136omtXRfefSX 4/f+wFK3uMs/ZaLP3Ng83fXcWgZL8UkbXlWViz2KuDD7Y4iHvOGq/MX1W9L0N06vdlojEca0 yORjQN9Eg7csZ1/ox3leeWc750uf2YEtiUmqb3weX1FiKc5INNRiLipOBACIYDpcVQIAAA== Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 07:21:24 -0000 Hi, As Andrew has provided the clarifications, I also support moving the draft = forward. Regards, Christer -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Leis, Peter (NSN - DE/Munich) Sent: 20. maaliskuuta 2013 9:16 To: dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted +1 Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Georg Mayer Sent: Friday, March 15, 2013 4:04 PM To: 'Atle Monrad'; 'Dale R. Worley'; dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted Hello, I fully support these drafts going forward now. It would be great seeing th= em completed within short time. After Andrews clarifications I do not see a= ny reason to hold them back any longer. Thanks, Georg=20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftra= g von Atle Monrad Gesendet: Dienstag, 12. M=E4rz 2013 23:35 An: Dale R. Worley; dispatch@ietf.org Betreff: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted Dale / all >From a 3GPP-perspective, I would like to see this draft being completed asa= p I would be happy if Gonzalo could look at Andrews summary provided to the l= ist today to see if he agree that the various concerns are discussed and me= t. I hope that Gonzalo can take the draft further. Thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management Ericsson -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dale R. Worley Sent: 12. mars 2013 14:17 To: dispatch@ietf.org Subject: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, dra= ft-allen-dispatch-imei-urn-as-instanceid submitted What is the plan for moving forward with the IMEI drafts? As far as I can = see, they're in fine shape. Dale _______________________________________________ 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 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From jan.van.geel@belgacom.be Wed Mar 20 00:27:06 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9970421F8B97 for ; Wed, 20 Mar 2013 00:27:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSUx82bn4GHl for ; Wed, 20 Mar 2013 00:27:05 -0700 (PDT) Received: from mx13.belgacom.be (mx13.belgacom.be [195.13.15.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5531E21F8B96 for ; Wed, 20 Mar 2013 00:27:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,876,1355094000"; d="scan'208";a="23459615" Received: from a03005.bgc.net ([10.120.129.161]) by mx13.belgacom.be with ESMTP; 20 Mar 2013 08:27:03 +0100 X-TM-IMSS-Message-ID: <07c33bc00001c110@belgacom.be> Received: from A04022.BGC.NET ([10.120.135.23]) by belgacom.be ([10.120.129.161]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 07c33bc00001c110 ; Wed, 20 Mar 2013 08:27:03 +0100 Received: from A04067.BGC.NET ([10.121.135.38]) by A04022.BGC.NET ([10.120.135.23]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 08:27:03 +0100 From: "VAN GEEL Jan (CIS/SCC)" To: "dispatch@ietf.org" Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQGZmXhCHwixlArchpjazxQI+Ovj6wGanlphmQMUQiCAB1kwQP//8PGAgAASSzA= Date: Wed, 20 Mar 2013 07:27:02 +0000 Message-ID: <1E97FFD1485F1142BC075FF145A53A1E287508@A04067.BGC.NET> References: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> <7D2F7D7ADBA812449F25F4A69922881C081C7E@ESESSMB203.ericsson.se> <001c01ce218e$444ad2b0$cce07810$@gmx.com> <059F3547244B7F4DB728757635C2DC4B032DA1@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B12D5C0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B12D5C0@ESESSMB209.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.29.23] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 07:27:06 -0000 +1 Jan Van Geel IT and Network Specialist Belgacom CIS/SCC/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Christer Holmberg Sent: Wednesday 20 March 2013 08:21 To: Leis, Peter (NSN - DE/Munich); dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted Hi, As Andrew has provided the clarifications, I also support moving the draft = forward. Regards, Christer -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Leis, Peter (NSN - DE/Munich) Sent: 20. maaliskuuta 2013 9:16 To: dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted +1 Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Georg Mayer Sent: Friday, March 15, 2013 4:04 PM To: 'Atle Monrad'; 'Dale R. Worley'; dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted Hello, I fully support these drafts going forward now. It would be great seeing th= em completed within short time. After Andrews clarifications I do not see a= ny reason to hold them back any longer. Thanks, Georg -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftra= g von Atle Monrad Gesendet: Dienstag, 12. M=E4rz 2013 23:35 An: Dale R. Worley; dispatch@ietf.org Betreff: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted Dale / all >From a 3GPP-perspective, I would like to see this draft being completed asa= p I would be happy if Gonzalo could look at Andrews summary provided to the l= ist today to see if he agree that the various concerns are discussed and me= t. I hope that Gonzalo can take the draft further. Thanks /atle ________________________________ Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management Ericsson -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dale R. Worley Sent: 12. mars 2013 14:17 To: dispatch@ietf.org Subject: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, dra= ft-allen-dispatch-imei-urn-as-instanceid submitted What is the plan for moving forward with the IMEI drafts? As far as I can = see, they're in fine shape. Dale _______________________________________________ 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 _______________________________________________ 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 ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer From md3135@att.com Wed Mar 20 05:35:16 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C3421F88E5 for ; Wed, 20 Mar 2013 05:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 OVaxaf0EONuM for ; Wed, 20 Mar 2013 05:35:15 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6DB21F8788 for ; Wed, 20 Mar 2013 05:35:15 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 30da9415.4d2a5940.73578.00-556.198637.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 20 Mar 2013 12:35:15 +0000 (UTC) X-MXL-Hash: 5149ad0359f51dae-86dd8e8630f6fe4b97b9a898ccd62c04a5bc3935 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id efca9415.0.73534.00-397.198541.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 20 Mar 2013 12:35:14 +0000 (UTC) X-MXL-Hash: 5149ad022055c45e-6d34a01b4519ea0bd53cc945553997b61a50dfe5 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2KCZ8gE017522; Wed, 20 Mar 2013 08:35:08 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2KCZ0fi017432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Mar 2013 08:35:02 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 20 Mar 2013 12:34:46 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 08:34:46 -0400 From: "DOLLY, MARTIN C" To: "VAN GEEL Jan (CIS/SCC)" , "dispatch@ietf.org" Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: AQGZmXhCHwixlArchpjazxQI+Ovj6wGanlphmQMUQiCAB1kwQIAARMOAgAABlgCAABLH0A== Date: Wed, 20 Mar 2013 12:34:45 +0000 Message-ID: References: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> <7D2F7D7ADBA812449F25F4A69922881C081C7E@ESESSMB203.ericsson.se> <001c01ce218e$444ad2b0$cce07810$@gmx.com> <059F3547244B7F4DB728757635C2DC4B032DA1@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B12D5C0@ESESSMB209.ericsson.se> <1E97FFD1485F1142BC075FF145A53A1E287508@A04067.BGC.NET> In-Reply-To: <1E97FFD1485F1142BC075FF145A53A1E287508@A04067.BGC.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.89.54] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Pr4kmXw3 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=JdMneub6SNEA:10 a=IxTN5neDWAoA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=pWFVnISv1XkA:10 a=48vgC7mUAAAA:8 a=3NbZyPbkAAAA:8] X-AnalysisOut: [ a=fjcx6A9v-m8MEe7NL-4A:9 a=wPNLvfGTeEIA:10 a=TqKXRhSNJSUA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=VQUPCYMFwfwA:10 a=NWVoK91CQyQA:10 ] X-AnalysisOut: [a=j2W5gN3nx_W7OLwH:21 a=ArYJuP2mrbdaO7fK:21] Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 12:35:16 -0000 We support -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of VAN GEEL Jan (CIS/SCC) Sent: Wednesday, March 20, 2013 3:27 AM To: dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted +1 Jan Van Geel IT and Network Specialist Belgacom CIS/SCC/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Christer Holmberg Sent: Wednesday 20 March 2013 08:21 To: Leis, Peter (NSN - DE/Munich); dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted Hi, As Andrew has provided the clarifications, I also support moving the draft = forward. Regards, Christer -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Leis, Peter (NSN - DE/Munich) Sent: 20. maaliskuuta 2013 9:16 To: dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted +1 Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Georg Mayer Sent: Friday, March 15, 2013 4:04 PM To: 'Atle Monrad'; 'Dale R. Worley'; dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted Hello, I fully support these drafts going forward now. It would be great seeing th= em completed within short time. After Andrews clarifications I do not see a= ny reason to hold them back any longer. Thanks, Georg -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftra= g von Atle Monrad Gesendet: Dienstag, 12. M=E4rz 2013 23:35 An: Dale R. Worley; dispatch@ietf.org Betreff: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted Dale / all >From a 3GPP-perspective, I would like to see this draft being completed asa= p I would be happy if Gonzalo could look at Andrews summary provided to the l= ist today to see if he agree that the various concerns are discussed and me= t. I hope that Gonzalo can take the draft further. Thanks /atle ________________________________ Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management Ericsson -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dale R. Worley Sent: 12. mars 2013 14:17 To: dispatch@ietf.org Subject: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, dra= ft-allen-dispatch-imei-urn-as-instanceid submitted What is the plan for moving forward with the IMEI drafts? As far as I can = see, they're in fine shape. Dale _______________________________________________ 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 _______________________________________________ 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 ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From laura.liess.dt@googlemail.com Wed Mar 20 06:45:11 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAC321F851C for ; Wed, 20 Mar 2013 06:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 LZmL1JsoXZKm for ; Wed, 20 Mar 2013 06:45:10 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF3621F84F2 for ; Wed, 20 Mar 2013 06:45:10 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id er20so3007937lab.32 for ; Wed, 20 Mar 2013 06:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=yFqVvCKSEwfpxO/sDtefPkSJfVMzjBEfS+w1+BoAsYk=; b=UeKbAt2NGPMaG0z30qOt7uhfolipLQLhhF2qlThMNjAKTK444HSUjGUX65sf+BfoZX teqE5vpwMF668uVgo+rry/6oosalInNbjBMb3guePcEyQkZ+rrhzVuvV/vo4C0QY6DLZ 90i7/94Ar1j7utxS2M7HaQMA041DRTJeoP5crc0SWe4M8WT/OaithmTyFlhZeggOmNaX zXMMXIoIrCglHfX0hT0ROnUOpBtDT/eS2s/fowJw3nWs13+bTIlggUbYTB+E9xFPaBLg 5Jz4ZFrytECP+df7D6XtHVNv8v2jQ4ASSay4PjUsrI4UR59q0a8HZ9U7qaueJ1x4j+yT I+VA== MIME-Version: 1.0 X-Received: by 10.152.123.34 with SMTP id lx2mr5432285lab.52.1363787109104; Wed, 20 Mar 2013 06:45:09 -0700 (PDT) Received: by 10.114.95.99 with HTTP; Wed, 20 Mar 2013 06:45:08 -0700 (PDT) In-Reply-To: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> References: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> Date: Wed, 20 Mar 2013 14:45:08 +0100 Message-ID: From: Laura Liess To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=f46d0434bfea30033204d85b6e4a Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:45:11 -0000 --f46d0434bfea30033204d85b6e4a Content-Type: text/plain; charset=ISO-8859-1 I support moving forward with the drafts. Thank you Laura 2013/3/12 Dale R. Worley > What is the plan for moving forward with the IMEI drafts? As far as I > can see, they're in fine shape. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --f46d0434bfea30033204d85b6e4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support moving forward with the drafts.

Thank you
Laura

2013/3/12 Dale R. Worley = <worley@ariadne.= com>
What is the plan for moving forward with the= IMEI drafts? =A0As far as I
can see, they're in fine shape.

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

--f46d0434bfea30033204d85b6e4a-- From ricky.kaura@samsung.com Wed Mar 20 07:15:30 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E7821F8F7B for ; Wed, 20 Mar 2013 07:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 pPPXDm2OsTqg for ; Wed, 20 Mar 2013 07:15:29 -0700 (PDT) Received: from mailout3.w1.samsung.com (mailout3.w1.samsung.com [210.118.77.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE3821F8F5D for ; Wed, 20 Mar 2013 07:15:29 -0700 (PDT) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MJY005O1Q5WPO70@mailout3.w1.samsung.com> for dispatch@ietf.org; Wed, 20 Mar 2013 14:15:23 +0000 (GMT) X-AuditID: cbfec7f5-b7fd76d000007247-44-5149c47bad4c Received: from eusync1.samsung.com ( [203.254.199.211]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id 97.59.29255.B74C9415; Wed, 20 Mar 2013 14:15:23 +0000 (GMT) Received: from ex1.seri.co.uk ([106.1.8.3]) by eusync1.samsung.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0MJY00E5CQ9N7WB0@eusync1.samsung.com> for dispatch@ietf.org; Wed, 20 Mar 2013 14:15:23 +0000 (GMT) Received: from ex1.seri.co.uk ([2002:6a01:803::6a01:803]) by ex1.seri.co.uk ([2002:6a01:803::6a01:803]) with mapi id 14.01.0218.012; Wed, 20 Mar 2013 14:16:26 +0000 From: Ricky Kaura To: "dispatch@ietf.org" Thread-topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-index: Ac4lOrs953R+CS1GTgOJ4L1GXy0gZgAOlgMw Date: Wed, 20 Mar 2013 14:16:25 +0000 Message-id: <1362EB141A7E674397C8F8EB62AB1FA96A78217B@ex1.seri.co.uk> References: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> <7D2F7D7ADBA812449F25F4A69922881C081C7E@ESESSMB203.ericsson.se> <001c01ce218e$444ad2b0$cce07810$@gmx.com> <059F3547244B7F4DB728757635C2DC4B032DA1@DEMUMBX003.nsn-intra.net> In-reply-to: <059F3547244B7F4DB728757635C2DC4B032DA1@DEMUMBX003.nsn-intra.net> Accept-Language: en-GB, en-US Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Originating-IP: [106.1.8.248] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable MIME-version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsVy+t/xy7rVRzwDDbY3qlgsnbSA1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGYd+r2cp6OeruDrvIksD43vuLkZODgkBE4lLy7rZIGwxiQv3 1gPZXBxCAksZJTbenQ3lTGeSWHH8IAuEs4JRYvuPFWAtbALaEq86elhAbBEg++iqLmaQImGB ZkaJS/1XwdpFBFoYJY7P7WWCqDKSuNt9EcxmEVCVmLX3OiuIzSvgKrFl6gxWiBUfGCXO9a0A G8sp4CfRv/IxWBGjgKzEl8bVzCA2s4C4RHPrTRaIywUkluw5zwxhi0q8fPyPFcKWl2ha2Q1V ryPR+/0blK0t8eTdBajFghI/Jt9jmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRtHU0uSC4qT0XCO9 4sTc4tK8dL3k/NxNjJCo+bqDcekxq0OMAhyMSjy8L2d7BAqxJpYVV+YeYpTgYFYS4f283zNQ iDclsbIqtSg/vqg0J7X4ECMTB6dUA2OtPwvro3zW/fsdJ0ZpOUcW7qne/FPiWeXaOX0MQSYV i158//0/+MK12kvlRY8PuL0NbLJT2zX9y8ltd3ff3JhR8e1Z6hfmUIZzgu8PzpzJYdsyWb1b ZH7D644V2Rw/Ls9e3e6o3rT7ZULC6SXlM0osH2jfzs5pLeU59mORGedV4+a1QaolTvFKLMUZ iYZazEXFiQCs1mrxeAIAAA== Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 14:15:30 -0000 Hello, I also support these drafts going forward. Regards, =A0 Ricky Kaura. Principal Standards Engineer Standands and Industry Affairs (SIA) Samsung Research and development institute United Kingdom (SRUK) Tel:=A0=A0 +44 (0) 1784 428 600 Ext 635; Mob: +44 (0) 7760 761514; Fax: +44= (0) 1784 428 610 Email: ricky.kaura@samsung.com; Skype: rickykaura; Yahoo: rkaura1969 Samsung Electronics (UK) Limited Registered number: 03086621 Registered address: Communications house, South Street, Staines, Middlesex = TW18 4QE. -----Original Message----- From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com]=20 Sent: 20 March 2013 07:16 To: dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted +1 Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Georg Mayer Sent: Friday, March 15, 2013 4:04 PM To: 'Atle Monrad'; 'Dale R. Worley'; dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted Hello, I fully support these drafts going forward now. It would be great seeing th= em completed within short time. After Andrews clarifications I do not see a= ny reason to hold them back any longer. Thanks, Georg=20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auftra= g von Atle Monrad Gesendet: Dienstag, 12. M=E4rz 2013 23:35 An: Dale R. Worley; dispatch@ietf.org Betreff: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and,= draft-allen-dispatch-imei-urn-as-instanceid submitted Dale / all From rlb@ipv.sx Wed Mar 20 07:27:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6415D21F8FD0 for ; Wed, 20 Mar 2013 07:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 VxHDesvnXGBG for ; Wed, 20 Mar 2013 07:27:28 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C772021F8FDB for ; Wed, 20 Mar 2013 07:27:17 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id 16so1662724obc.19 for ; Wed, 20 Mar 2013 07:27:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=v63Ouw+PMFmNm9MaunxKt5Bnl3IUuXKT4nv31ZjJaPk=; b=YPVrY5ULqs1MPvYhY7/unX8c75gBkxZHcKeXFbz27bG+VW5iXvhd422WxQp/Oza6ai 66Wa3oTvk9GynyBsFjHQdhck0et2GZZs+haIi8S7AtUqoS6i7+QaYH6yUVhuTpai6/cM EKSmNCbOgD9DshPKAMOwfvt8SNFLWb0Dfz9eh0tp2P3y5mpiG85acJhMT/lNBr3Bt56W RwLN3Ul4oISrzirIk1nHC1QtTOdE21zQCC1fBrVDgU4wUvQuHI47nV6HMQWpLg9URHtE feCHogCpqejKgIk0Skx2Djtdi47tNl5q/rpA6N3dI1SevHj13PAnOH6zaC+Khaa4nLyU Ezxg== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr4267848oec.116.1363789637055; Wed, 20 Mar 2013 07:27:17 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Wed, 20 Mar 2013 07:27:16 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: References: Date: Wed, 20 Mar 2013 10:27:16 -0400 Message-ID: From: Richard Barnes To: Mary Barnes Content-Type: multipart/alternative; boundary=bcaec5523bb6ddd64604d85c0443 X-Gm-Message-State: ALoCoQm2W0LnPbQh7CIt4yfG/iQoF+PGszovLJ9hqMiJ4ST4DmUz6600Ryc6PvlsoCmRnC349Nah Cc: DISPATCH , "rai@ietf.org" Subject: Re: [dispatch] [RAI] Fwd: Call for nominations: FCC CSRIC IV X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 14:27:28 -0000 --bcaec5523bb6ddd64604d85c0443 Content-Type: text/plain; charset=ISO-8859-1 Thanks for forwarding this, Mary. In case people are wondering, this is a very worthwhile activity to be involved in, especially for folks in the US. A lot of what CSRIC does is collect information on the state of the art in communications. As usual with the FCC, they have good contact with the carriers, but they really need input from the Internet community. --Richard On Tue, Mar 19, 2013 at 2:57 PM, Mary Barnes wrote: > This might be of interest to some folks. > > Mary. > > ---------- Forwarded message ---------- > From: Henning Schulzrinne > Date: Tue, Mar 19, 2013 at 1:50 PM > Subject: Call for nominations: FCC CSRIC IV > To: "tccc@lists.cs.columbia.edu" , > "ietf@ietf.org" > > > Please see > http://www.fcc.gov/document/fcc-extends-nominations-deadline-csric-april-12-2013 > > > > The duties of the Council will be to make recommendations to the FCC > regarding actions it can > take to promote communications security, reliability, and resiliency. > The duties of the Council > may include: > a. Developing and recommending to the FCC best practices and actions > it can take that > promote reliable communications services, including 911, Enhanced 911, and > Next > Generation 911 service. > b. Developing and recommending to the FCC best practices and actions > it can take to > improve the security of networks and mobile devices. > c. Identifying and recommending to the FCC a set of best practices to make > communications networks, including broadband networks and Voice over > Internet > Protocol (VoIP) systems, more secure and resilient. > d. Developing recommendations for actions the FCC should take to > enhance the ability > of the public to receive timely and accurate emergency alerts and > warnings, including > ways to leverage advanced communications technologies and the > Internet, including > broadband technologies and social media platforms. > e. Make recommendations with respect to such additional topics as the FCC > may > specify. > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai > --bcaec5523bb6ddd64604d85c0443 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for forwarding this, Mary.

In case people are won= dering, this is a very worthwhile activity to be involved in, especially fo= r folks in the US. =A0A lot of what CSRIC does is collect information on th= e state of the art in communications. =A0As usual with the FCC, they have g= ood contact with the carriers, but they really need input from the Internet= community. =A0

--Richard


= On Tue, Mar 19, 2013 at 2:57 PM, Mary Barnes <mary.ietf.barnes@g= mail.com> wrote:
This might be of interest to some folks.

Mary.

---------- Forwarded message ----------
From: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Date: Tue, Mar 19, 2013 at 1:50 PM
Subject: Call for nominations: FCC CSRIC IV
To: "tccc@lists.cs.colum= bia.edu" <tccc@li= sts.cs.columbia.edu>,
"ietf@ietf.org" <ietf@ietf.org>


Please see http://www.fcc.gov/document/= fcc-extends-nominations-deadline-csric-april-12-2013



The duties of the Council will be to make recommendations to the FCC
regarding actions it can
take to promote communications security, reliability, and resiliency.
The duties of the Council
may include:
a. Developing and recommending to the FCC best practices and actions
it can take that
promote reliable communications services, including 911, Enhanced 911, and = Next
Generation 911 service.
b. Developing and recommending to the FCC best practices and actions
it can take to
improve the security of networks and mobile devices.
c. Identifying and recommending to the FCC a set of best practices to make<= br> communications networks, including broadband networks and Voice over Intern= et
Protocol (VoIP) systems, more secure and resilient.
d. Developing recommendations for actions the FCC should take to
enhance the ability
of the public to receive timely and accurate emergency alerts and
warnings, including
ways to leverage advanced communications technologies and the
Internet, including
broadband technologies and social media platforms.
e. Make recommendations with respect to such additional topics as the FCC m= ay
specify.
_______________________________________________
RAI mailing list
RAI@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/rai

--bcaec5523bb6ddd64604d85c0443-- From richard@shockey.us Wed Mar 20 08:17:09 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C7921F8E2C for ; Wed, 20 Mar 2013 08:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 tbOVJ+L51Ziy for ; Wed, 20 Mar 2013 08:17:01 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 7ED5E21F8825 for ; Wed, 20 Mar 2013 08:16:55 -0700 (PDT) Received: (qmail 22519 invoked by uid 0); 20 Mar 2013 15:16:31 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy12.bluehost.com with SMTP; 20 Mar 2013 15:16:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=lsfyXztelqGt19m2QY7ZZYuBGJaQ86UfhqLwCpV4ooY=; b=pbsh5yZZWvvX3c8cx+xOpwQvTBEPDiZwR/mP+jqYJOjI6u4jT28BS7mM4TMAyj2lxgYTivSq3mrDl/IpsqP1eEUE6B2FsztXIleuzvCaS7x9C4VFm3ccnttVL9KxTYd8; Received: from [72.66.111.101] (port=55030 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UIKkg-0001ir-Sc; Wed, 20 Mar 2013 09:16:31 -0600 From: "Richard Shockey" To: "'Richard Barnes'" , "'Mary Barnes'" References: In-Reply-To: Date: Wed, 20 Mar 2013 11:16:29 -0400 Message-ID: <00b501ce257d$e6d63220$b4829660$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B6_01CE255C.5FCBBE10" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHM39NbItDCx0ONW/EtCFm+2sTEjwFkznW7AZhYKPWYmU8vEA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.101 authed with richard@shockey.us} Cc: 'DISPATCH' , rai@ietf.org Subject: Re: [dispatch] [RAI] Fwd: Call for nominations: FCC CSRIC IV X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 15:17:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B6_01CE255C.5FCBBE10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Indeed .. Yours truly has served on CSRIC III for the past two years. It recently concluded its chartered work. (Imagine that concluding ones chartered work in 2 years) http://www.fcc.gov/encyclopedia/communications-security-reliability-and-inte roperability-council-iii Mary and Richard are right this is important work and the FCC .and many national regulatory agencies need all the technical clue we can give them. From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Wednesday, March 20, 2013 10:27 AM To: Mary Barnes Cc: DISPATCH; rai@ietf.org Subject: Re: [dispatch] [RAI] Fwd: Call for nominations: FCC CSRIC IV Thanks for forwarding this, Mary. In case people are wondering, this is a very worthwhile activity to be involved in, especially for folks in the US. A lot of what CSRIC does is collect information on the state of the art in communications. As usual with the FCC, they have good contact with the carriers, but they really need input from the Internet community. --Richard On Tue, Mar 19, 2013 at 2:57 PM, Mary Barnes < mary.ietf.barnes@gmail.com> wrote: This might be of interest to some folks. Mary. ---------- Forwarded message ---------- From: Henning Schulzrinne < Henning.Schulzrinne@fcc.gov> Date: Tue, Mar 19, 2013 at 1:50 PM Subject: Call for nominations: FCC CSRIC IV To: " tccc@lists.cs.columbia.edu" < tccc@lists.cs.columbia.edu>, " ietf@ietf.org" < ietf@ietf.org> Please see http://www.fcc.gov/document/fcc-extends-nominations-deadline-csric-april-12- 2013 The duties of the Council will be to make recommendations to the FCC regarding actions it can take to promote communications security, reliability, and resiliency. The duties of the Council may include: a. Developing and recommending to the FCC best practices and actions it can take that promote reliable communications services, including 911, Enhanced 911, and Next Generation 911 service. b. Developing and recommending to the FCC best practices and actions it can take to improve the security of networks and mobile devices. c. Identifying and recommending to the FCC a set of best practices to make communications networks, including broadband networks and Voice over Internet Protocol (VoIP) systems, more secure and resilient. d. Developing recommendations for actions the FCC should take to enhance the ability of the public to receive timely and accurate emergency alerts and warnings, including ways to leverage advanced communications technologies and the Internet, including broadband technologies and social media platforms. e. Make recommendations with respect to such additional topics as the FCC may specify. _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai ------=_NextPart_000_00B6_01CE255C.5FCBBE10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Indeed = .. =

 

Yours = truly has served on CSRIC III for the past two years. It recently = concluded its chartered work.  = (Imagine that concluding ones chartered work in 2 years) =

 

http://www.fcc.gov/encyclopedia/comm= unications-security-reliability-and-interoperability-council-iii=

 

Mary = and Richard are right this is important work and the FCC …and  many national regulatory = agencies need all the technical clue we can give them. =

 

From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Wednesday, March 20, 2013 10:27 AM
To: = Mary Barnes
Cc: DISPATCH; rai@ietf.org
Subject: Re: = [dispatch] [RAI] Fwd: Call for nominations: FCC CSRIC = IV

 

Thanks for = forwarding this, Mary.

 

In = case people are wondering, this is a very worthwhile activity to be = involved in, especially for folks in the US.  A lot of what CSRIC = does is collect information on the state of the art in communications. =  As usual with the FCC, they have good contact with the carriers, = but they really need input from the Internet community. =  

 

--Richard

 

On Tue, Mar = 19, 2013 at 2:57 PM, Mary Barnes <mary.ietf.barnes@gmail.com> = wrote:

This might be of interest to some = folks.

Mary.


---------- Forwarded message = ----------
From: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Date: Tue, Mar 19, 2013 at = 1:50 PM
Subject: Call for nominations: FCC CSRIC IV
To: = "tccc@lists.cs.columbia.edu" <tccc@lists.cs.columbia.edu>,
"ietf@ietf.org" <ietf@ietf.org>


Please see = http://www.fcc.gov/document/fcc-exte= nds-nominations-deadline-csric-april-12-2013



The duties of the = Council will be to make recommendations to the FCC
regarding actions = it can
take to promote communications security, reliability, and = resiliency.
The duties of the Council
may include:
a. = Developing and recommending to the FCC best practices and actions
it = can take that
promote reliable communications services, including = 911, Enhanced 911, and Next
Generation 911 service.
b. Developing = and recommending to the FCC best practices and actions
it can take = to
improve the security of networks and mobile devices.
c. = Identifying and recommending to the FCC a set of best practices to = make
communications networks, including broadband networks and Voice = over Internet
Protocol (VoIP) systems, more secure and = resilient.
d. Developing recommendations for actions the FCC should = take to
enhance the ability
of the public to receive timely and = accurate emergency alerts and
warnings, including
ways to leverage = advanced communications technologies and the
Internet, = including
broadband technologies and social media platforms.
e. = Make recommendations with respect to such additional topics as the FCC = may
specify.

____________________________________= ___________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/mailman/listinf= o/rai

<= /div>

 

------=_NextPart_000_00B6_01CE255C.5FCBBE10-- From tanakai@nttdocomo.co.jp Wed Mar 20 16:42:05 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0472921F8675 for ; Wed, 20 Mar 2013 16:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1] 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 3tJKRTmvoK9w for ; Wed, 20 Mar 2013 16:42:04 -0700 (PDT) Received: from zcsg-mailou12.is.nttdocomo.co.jp (dish-sg.nttdocomo.co.jp [202.19.227.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5751F21F8615 for ; Wed, 20 Mar 2013 16:42:03 -0700 (PDT) Received: from zcsg-mailmd13.is.nttdocomo.co.jp (zcsg-mailmd10.is.nttdocomo.co.jp [10.160.124.159]) by zcsg-mailou12.is.nttdocomo.co.jp (Postfix) with ESMTP id DBEAB30006 for ; Thu, 21 Mar 2013 08:42:02 +0900 (JST) Received: from zcsg-mailmf11.is.nttdocomo.co.jp (zcsg-mailmf10.is.nttdocomo.co.jp [10.160.124.165]) by zcsg-mailmd13.is.nttdocomo.co.jp (NTT DoCoMo Mail System) with ESMTP id <0MJZ00E3MGI2UZ00@NTTDoCoMo.co.jp> for dispatch@ietf.org; Thu, 21 Mar 2013 08:42:02 +0900 (JST) Received: from zcsg-mailua12.is.nttdocomo.co.jp (zcsg-mailua10.is.nttdocomo.co.jp [10.160.124.163]) by zcsg-mailmf11.is.nttdocomo.co.jp (Postfix) with ESMTP id 8FAFB118005 for ; Thu, 21 Mar 2013 08:42:02 +0900 (JST) Received: from AKR9TF88N (akr9tf88n.docomo.docomogr.net [10.18.216.52]) by zcsg-mailua12.is.nttdocomo.co.jp (NTT DoCoMo Mail System) with ESMTPA id <0MJZ00AIEGHZ7TC0@NTTDoCoMo.co.jp> for dispatch@ietf.org; Thu, 21 Mar 2013 08:42:02 +0900 (JST) Date: Thu, 21 Mar 2013 08:41:59 +0900 From: Itsuma TANAKA In-reply-to: <1362EB141A7E674397C8F8EB62AB1FA96A78217B@ex1.seri.co.uk> To: dispatch@ietf.org Message-id: <00d901ce25c4$83a61340$8af239c0$@nttdocomo.co.jp> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=UTF-8 Content-language: ja Content-transfer-encoding: quoted-printable Thread-index: AQGZmXhCHwixlArchpjazxQI+Ovj6wGanlphApVSnpgCI81RXQLAFqfJmM+3K1A= References: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> <7D2F7D7ADBA812449F25F4A69922881C081C7E@ESESSMB203.ericsson.se> <001c01ce218e$444ad2b0$cce07810$@gmx.com> <059F3547244B7F4DB728757635C2DC4B032DA1@DEMUMBX003.nsn-intra.net> <1362EB141A7E674397C8F8EB62AB1FA96A78217B@ex1.seri.co.uk> X-TM-AS-MML: No Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 23:42:05 -0000 Dear All, I fully support these drafts going forward. Regards, Itsuma Tanaka -------------------------------------------------------- Itsuma TANAKA (=E7=94=B0=E4=B8=AD=E5=A8=81=E6=B4=A5=E9=A6=AC) GSMA IREG Vice Chair / IREG Packet Chair NTT DOCOMO, Inc. -------------------------------------------------------- -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Ricky Kaura Sent: Wednesday, March 20, 2013 11:16 PM To: dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn = and, draft-allen-dispatch-imei-urn-as-instanceid submitted Hello, I also support these drafts going forward. Regards, =20 Ricky Kaura. Principal Standards Engineer Standands and Industry Affairs (SIA) Samsung Research and development institute United Kingdom (SRUK) Tel: +44 (0) 1784 428 600 Ext 635; Mob: +44 (0) 7760 761514; Fax: +44 = (0) 1784 428 610 Email: ricky.kaura@samsung.com; Skype: rickykaura; Yahoo: rkaura1969 = Samsung Electronics (UK) Limited Registered number: 03086621 Registered = address: Communications house, South Street, Staines, Middlesex TW18 = 4QE. -----Original Message----- From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] Sent: 20 March 2013 07:16 To: dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn = and, draft-allen-dispatch-imei-urn-as-instanceid submitted +1 Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext Georg Mayer Sent: Friday, March 15, 2013 4:04 PM To: 'Atle Monrad'; 'Dale R. Worley'; dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn = and, draft-allen-dispatch-imei-urn-as-instanceid submitted Hello, I fully support these drafts going forward now. It would be great seeing = them completed within short time. After Andrews clarifications I do not = see any reason to hold them back any longer. Thanks, Georg=20 -----Urspr=C3=BCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Atle Monrad Gesendet: Dienstag, 12. M=C3=A4rz 2013 23:35 An: Dale R. Worley; dispatch@ietf.org Betreff: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn = and, draft-allen-dispatch-imei-urn-as-instanceid submitted Dale / all _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From prvs=37953a0889=jbakker@blackberry.com Sun Mar 24 12:06:33 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1241C21F8DD6 for ; Sun, 24 Mar 2013 12:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BQz--4BwqKPo for ; Sun, 24 Mar 2013 12:06:32 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id E129C21F8DB4 for ; Sun, 24 Mar 2013 12:06:31 -0700 (PDT) X-AuditID: 0a41282f-b7fa06d000002431-10-514f4ea92102 Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) by mhs060cnc.rim.net (SBG) with SMTP id EC.E6.09265.9AE4F415; Sun, 24 Mar 2013 14:06:18 -0500 (CDT) Received: from XMB103ADS.rim.net ([fe80::e54b:97d9:3777:f8dc]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0328.009; Sun, 24 Mar 2013 14:06:17 -0500 From: John-Luc Bakker To: "dispatch@ietf.org" Thread-Topic: New Version Notification for draft-avasarala-dispatch-comm-div-notification-11.txt Thread-Index: AQHOKLV849xoT4TCRk2btJ8OV2AOi5i1Gv3g Date: Sun, 24 Mar 2013 19:06:16 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA35D343DA@XMB103ADS.rim.net> References: <20130324173154.5139.13198.idtracker@ietfa.amsl.com> In-Reply-To: <20130324173154.5139.13198.idtracker@ietfa.amsl.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsXC5Zyvo7vKzz/Q4OUuFoulkxawOjB6LFny kymAMaqB0SYpsaQsODM9T9/OJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScx Mze1SEkhM8VWyURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb7 61pYmFrqGirZ6SZ08mRM+TeduWCBdcWyT9dZGhjvWHYxcnJICJhI/Hmwhw3CFpO4cG89kM3F ISSwklGi7/BCZghnK6PE3XXHwarYBPQkVkxexQhiiwhoSxxd1cUMYgsLJEp87d7KDBFPkmg5 9YEVwjaSeLLyPVg9i4CqxOvmPWBxXgE3iQ+brrOA2EICDhI/t7aC2ZwCjhK3WtuYQGxGAVmJ 3Wevg9nMAuISt57MZ4K4VEBiyZ7zzBC2qMTLx/9YIWxFiRl75gPZHED1mhLrd+lDtCpKTOl+ yA6xVlDi5MwnLBMYRWchmToLoWMWko5ZSDoWMLKsYhTMzSg2MDNIzkvWK8rM1ctLLdnECIp8 Rw39HYxv31scYhTgYFTi4TVw9Q8UYk0sK67MPcQowcGsJMJ7RxsoxJuSWFmVWpQfX1Sak1p8 iNEVGCYTmaW4k/OBSSmvJN7YwAA3R0mc99din0AhgXRg6slOTS1ILYKZw8TBCbKHS0qkGJhA UosSS0sy4kFpLr4YmOikGhiFp9YorZu6vUBy2sQiZYkV65+er8n2+ndo6cOKXTcfMNgazD7K 5p/vuqnAj3u23MZAZxt907OOa1aclnz63MbzZq7E8mm3HSsz5s5cb8RlsTB3U08o3/ZNW070 z9456+fFzcd/7qkofH3uk/SldPUzq3gbfnxqttivrrfxeMbCl5LXXT8kKSWzKrEUZyQaajEX FScCAL7kpog9AwAA Subject: [dispatch] FW: New Version Notification for draft-avasarala-dispatch-comm-div-notification-11.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 19:06:33 -0000 SGkgYWxsLA0KDQpBIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWF2YXNhcmFsYS1kaXNwYXRjaC1j b21tLWRpdi1ub3RpZmljYXRpb24tMTEgd2FzIG1hZGUgYXZhaWxhYmxlLiBOb3RlIHRoYXQg YXQgbGVhc3Qgb25lIG1vcmUgcmV2aXNpb24gb2YgdGhpcyBkcmFmdCBtYXkgYmUgcmVxdWly ZWQuIEZvciBleGFtcGxlLCB0aGUgTUlNRSB0eXBlIGlzIG5vdyBwcm9wb3NlZCB0byBiZSAi dm5kLjNncHAuY29tbS1kaXYtaW5mbyt4bWwiIGFuZCB0aGUgcmVnaXN0cmF0aW9uIHRlbXBs YXRlIGZvciBpdCBpcyB0byBiZSBwcm92aXNpb25hbGx5IGluY2x1ZGVkIGluIDNHUFAgVFMg MjQuNjA0LiBUaGlzIHdpbGwgdGhlbiBjYXVzZSB0aGUgcmVmZXJlbmNlcyBmcm9tIHRoaXMg ZHJhZnQgdG8gM0dQUCBUU2VzIHRvIGJlIHVwZGF0ZWQuDQoNCkFzIHRoZSBlZGl0b3IgSSB0 b29rIHRoZSBmcmVlZG9tIHRvIGdyZWF0bHkgcmVkdWNlIHRoZSBzaXplIG9mIHRoZSBkcmFm dCBieSByZWZlcmVuY2luZyB0byAzR1BQIFRTIDI0LjYwNCBtb3JlIGV4dGVuc2l2ZWx5LiBU aGUgU0lQIEV2ZW50cyBzcGVjaWZpY2F0aW9uIChSRkMgMzI2NSkgcmVxdWlyZXMgdGhhdDoN Ci0gYm9kaWVzIHRvIGJlIHVzZWQgYXMgcGFydCBvZiB0aGUgZXZlbnQgcGFja2FnZSBhcmUg c3BlY2lmaWVkOyBvciANCi0gZGV0YWlsZWQgc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBzeW50 YXggYW5kIHNlbWFudGljcyBvZiBzdWNoIGEgYm9keSBhcmUgY2l0ZWQuICANCkJ5IGNpdGlu ZyB0byBUUyAyNC42MDQgbW9yZSBmcmVxdWVudGx5LCBJIGdyZWF0bHkgcmVkdWNlZCB0aGUg c2l6ZSBvZiB0aGlzIGRyYWZ0OyB0aGUgZGV0YWlsZWQgc3BlY2lmaWNhdGlvbiBpcyBhbmQg aGFzIGFsd2F5cyBiZWVuIGluIDNHUFAgVFMgMjQuNjA0LiANCg0KW1FdIERvIHlvdSBoYXZl IGNvbmNlcm5zIHdpdGggdGhlIHByaW5jaXBsZSBvZiByZWZlcmVuY2luZyBtb3JlIGV4dGVu c2l2ZWx5IHRvIDNHUFAgVFMgMjQuNjA0Pw0KDQpBZGRpdGlvbmFsbHksIHRoZSBmb2xsb3dp bmcgY29tbWVudHMgd2VyZSByZWNlaXZlZCBmcm9tIHRoZSBsaXN0Og0KLSBDb3VsZCBhbGwg bWVudGlvbmluZyBvZiBDRElWTiBvbmx5IHdvcmtpbmcgb24gSU1TIC8gVElTUEFOIGJlIHJl bW92ZWQgZnJvbSB0aGUgZHJhZnQ/IENESVZOIGNvdWxkIGp1c3QgZGVmaW5lZCBhcyBhIGdl bmVyYWwgc2VydmljZS4gDQpbcmVzcG9uc2VdIENESVZOIGRlcGVuZHMgb24gSU1TIC8gVElT UEFOLWJhc2VkIENESVYgZmVhdHVyZXMgdGhhdCBhcmUgZGVmaW5lZCBpbiAzR1BQIFRTIDI0 LjYwNCBhbmQgM0dQUCBUUyAyNC4yMjkuIEFkZGl0aW9uYWxseSwgb3ZlciB0aGUgeWVhcnMg bm8gQ0RJVk4gd29yayBoYXMgc3RhcnRlZCBvdXRzaWRlIG9mIHRoZSAzR1BQIGFwcGxpY2F0 aW9uIHdvcmxkLiANCg0KLSBUaGUgZHJhZnQgZG9lcyBub3QgbWVudGlvbiBhbnl0aGluZyBh Ym91dCBQVUJMSVNILg0KW3Jlc3BvbnNlXSBUaGUgdXNlIGNhc2UgZm9yIFBVQkxJU0ggaXMg dXBkYXRpbmcgQ0RJViBydWxlcyBpbiB0aGUgbmV0d29yayBkdWUgdG8gcHVzaGluZyBhIERO RCBidXR0b24uIFRoaXMgZHJhZnQgZG9lcyBub3QgaGF2ZSAidXBkYXRpbmcgb2YgQ0RJViBy dWxlcyIgd2l0aGluIGl0cyBzY29wZS4gVGhpcyBkcmFmdCBjb25jZXJucyBpdHNlbGYgd2l0 aCB0aGUgcmVnaXN0ZXJpbmcgb2YgYW4gZXZlbnQgcGFja2FnZSBuYW1lIGFuZCBkZXNjcmli ZXMgYSBmaWx0ZXIgdGhhdCBjYXVzZXMgbm90aWZpY2F0aW9ucyB0byBiZSBzZW50IHdoZW4g YSBmaWx0ZXIgaXMgbWF0Y2hlZCBhbmQgd2hlbiBhIENESVYgaXMgZGV0ZWN0ZWQuIEkuZS4g dGhlIGluZm9ybWF0aW9uIGluIHRoZSBldmVudCBwYWNrYWdlIGluZm9ybXMgdGhlIFVBIGlm IGEgZGl2ZXJzaW9uIGhhcyBvY2N1cnJlZCwgQ0RJVk4gZG9lcyBub3QgY2F1c2UgZGl2ZXJz aW9ucyB0byBvY2N1ciBhcyBzdWdnZXN0ZWQgYnkgdGhlIFBVQkxJU0ggdXNlIGNhc2UuIA0K DQotIFBhdWwgcG9pbnRlZCBvdXQgdGhlIE1JTUUgdHlwZSB3YXMgbWlzc2luZy4gDQpbcmVz cG9uc2VdIFRoZSBwcm9wb3NlZCBNSU1FIHR5cGUgdGhhdCBjb3ZlcnMgdGhlIFhNTCBTY2hl bWEgZm91bmQgaW4gVFMgMjQuNjA0IGlzICJ2bmQuM2dwcC5jb21tLWRpdi1pbmZvK3htbCIu IEFnYWluLCBUUyAyNC42MDQgbmVlZHMgc29tZSB1cGRhdGluZyB0byBiZSBhbGlnbmVkIHdp dGggdGhpcyB2ZXJzaW9uIG9mIGRyYWZ0LWF2YXNhcmFsYS1kaXNwYXRjaC1jb21tLWRpdi1u b3RpZmljYXRpb24uIFRTIDI0LjYwNCBjdXJyZW50bHkgcmVmZXJlbmNlcyBkcmFmdC1hdmFz YXJhbGEtZGlzcGF0Y2gtY29tbS1kaXYtbm90aWZpY2F0aW9uLTA3LiBUaGUgYWxpZ25pbmcg b2YgVFMgMjQuNjA0IHdpdGggdGhlIGV2b2x2ZWQgZHJhZnQtYXZhc2FyYWxhLWRpc3BhdGNo LWNvbW0tZGl2LW5vdGlmaWNhdGlvbiB3aWxsIGJlIGNvbXBsZXRlZCBzaG9ydGx5IGFuZCB3 aWxsIHJlc3VsdCBpbiBhIGRyYWZ0LWF2YXNhcmFsYS1kaXNwYXRjaC1jb21tLWRpdi1ub3Rp ZmljYXRpb24tMTIuDQoNCi0gUGF1bCBhc2tlZCBhIEZTTSBxdWVzdGlvbjogIklzIGl0IHJl YWxseSB0aGUgaW50ZW50IHRoYXQgdGhlIHN0YXRlIG1hY2hpbmUgaXMgYWZmZWN0ZWQgYnkg dGhlIHN1YnNjcmliZXIgZmlsdGVyPyBUaGF0IHNlZW1zIHdyb25nLiBUaGF0IG1lYW5zIHRo YXQgYSBzdWJzY3JpcHRpb24gcmVmcmVzaCB0aGF0IGNoYW5nZXMgdGhlIGZpbHRlciBjcml0 ZXJpYSBjb3VsZCBsb3NlIGFuIGV2ZW50LiBBbHNvLCBpcyB0aGUgRlNNIGFzc29jaWF0ZWQg d2l0aCB0aGUgc3Vic2NyaWJlciwgb3Igd2l0aCB0aGUgc3Vic2NyaXB0aW9uPyAoSU9XLCBp ZiB0aGUgc2FtZSBzdWJzY3JpYmVyIGhhcyB0d28gY29uY3VycmVudCBzdWJzY3JpcHRpb25z LCBkb2VzIGl0IGhhdmUgdHdvIEZTTXMgb3Igb25lPykiDQpbcmVzcG9uc2VdIFRoZSBpbnRl bmRlZCB1c2Ugb2YgdGhlIGV2ZW50IHBhY2thZ2UgaXMgdG8gbm90aWZ5IGEgc3Vic2NyaWJl ciB3aGVuIGEgZGl2ZXJzaW9uIG9jY3VycyB0aGF0IG1hdGNoZXMgYSBzZXQgb2YgZmlsdGVy cyBwcm92aWRlZCB3aGVuIHN1YnNjcmliaW5nLiBUaGUgRlNNIGlzIHBlciBzdWJzY3JpYmVy J3MgVVJJLiBTbyBhIHN1YnNjcmliZXIgd2l0aCBtdWx0aXBsZSBVUklzIGNhbiBoYXZlIG11 bHRpcGxlIEZTTXMuIFdoZW5ldmVyIGEgZGlmZmVyZW50IChvciBmaXJzdCkgc2V0IG9mIHJ1 bGVzIGlzIHJlY2VpdmVkLCB0aGUgRlNNIChyZSlzdGFydHMgaW4gSURMRS4gRWFjaCB0cmFu c2l0aW9uIGluIHRoZSBGU00gaXMgY2F1c2VkIGJ5IHRoZSBkZXRlY3Rpb24gb2YgYSBkaXZl cnNpb24gZm9yIHRoZSBVUkkuIFRoZSBydWxlcyB0aGF0IGNhdXNlIGEgZGl2ZXJzaW9uIHRv IGhhcHBlbiBhcmUgZGlmZmVyZW50IGZyb20gdGhlIHJ1bGVzIHRoYXQgY2F1c2UgYSBub3Rp ZmljYXRpb24gdG8gaGFwcGVuLiBObyBub3RpZmljYXRpb25zIGFyZSBtaXNzZWQsIGFzIGxv bmcgYXMgdGhlIG5vdGlmaWVkIGRpdmVyc2lvbiBtYXRjaGVzIGEgZmlsdGVyLg0KDQpLaW5k IHJlZ2FyZHMsDQoNCglKTA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnXSANClNlbnQ6IFN1bmRheSwgTWFyY2ggMjQsIDIwMTMgMTI6MzIgUE0NClRvOiBKb2hu LUx1YyBCYWtrZXINCkNjOiByYW5qaXQuYXZhc2FyYWxhQHBvbHljb20uY29tDQpTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWF2YXNhcmFsYS1kaXNwYXRj aC1jb21tLWRpdi1ub3RpZmljYXRpb24tMTEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWF2YXNhcmFsYS1kaXNwYXRjaC1jb21tLWRpdi1ub3RpZmljYXRpb24tMTEu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEpvaG4gTHVjIEJha2tl ciBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJh ZnQtYXZhc2FyYWxhLWRpc3BhdGNoLWNvbW0tZGl2LW5vdGlmaWNhdGlvbg0KUmV2aXNpb246 CSAxMQ0KVGl0bGU6CQkgQSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgRXZl bnQgUGFja2FnZSBmb3IgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gSW5mb3JtYXRpb24gaW4g c3VwcG9ydCBvZiB0aGUgQ29tbXVuaWNhdGlvbiBEaXZlcnNpb24gKENESVYpIE5vdGlmaWNh dGlvbiAoQ0RJVk4pIENESVYgc2VydmljZQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDMtMjQN Ckdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxNQ0K VVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1hdmFzYXJhbGEtZGlzcGF0Y2gtY29tbS1kaXYtbm90aWZpY2F0aW9uLTExLnR4dA0K U3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWF2YXNhcmFsYS1kaXNwYXRjaC1jb21tLWRpdi1ub3RpZmljYXRpb24NCkh0bWxpemVkOiAg ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYXZhc2FyYWxhLWRpc3Bh dGNoLWNvbW0tZGl2LW5vdGlmaWNhdGlvbi0xMQ0KRGlmZjogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1hdmFzYXJhbGEtZGlzcGF0Y2gtY29t bS1kaXYtbm90aWZpY2F0aW9uLTExDQoNCkFic3RyYWN0Og0KICAgM0dQUCBhbmQgVElTUEFO IGFyZSBkZWZpbmluZyB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBmb3IgdGhlDQogICBD b21tdW5pY2F0aW9uIERpdmVyc2lvbiAoQ0RJVikgc2VydmljZSB1c2luZyBJUCBNdWx0aW1l ZGlhIChJTSkgQ29yZQ0KICAgTmV0d29yayAoQ04pIHN1YnN5c3RlbSAoSU1TKSBzdXBwbGVt ZW50YXJ5IHNlcnZpY2UuICBBcyBwYXJ0IG9mIENESVYsDQogICBhIFNJUCBiYXNlZCBldmVu dCBwYWNrYWdlIGlzIHVzZWQgZm9yIG5vdGlmeWluZyB1c2VycyBhYm91dA0KICAgZGl2ZXJz aW9ucyAocmUtZGlyZWN0aW9ucyBvciBmb3J3YXJkaW5nKSBvZiByZXF1ZXN0cyBmb3INCiAg IGNvbW11bmljYXRpb24gc2Vzc2lvbnMgdGFyZ2V0dGluZyB0aGUgdXNlci4gIFRoaXMgZG9j dW1lbnQgZGVmaW5lcw0KICAgdGhlIFNJUCBldmVudCBwYWNrYWdlIHRvIHN1cHBvcnQgc3Vi c2NyaXB0aW9uIGFuZCBub3RpZmljYXRpb24gb2YNCiAgIGRpdmVyc2lvbnMuICBUaGUgcHJv cG9zZWQgZXZlbnQgcGFja2FnZSBpcyBhcHBsaWNhYmxlIHRvIHRoZSBDRElWDQogICBzdXBw bGVtZW50YXJ5IHNlcnZpY2UgaW4gSU1TIGFuZCBtYXkgbm90IGJlIGFwcGxpY2FibGUgdG8g dGhlIGdlbmVyYWwNCiAgIGludGVybmV0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRo aXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFp biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1 ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3Ro ZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGlu Zm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVy IHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0 ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZy b20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciBy ZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGll bnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo= From fluffy@iii.ca Mon Mar 25 07:44:37 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E2D11E80C5 for ; Mon, 25 Mar 2013 07:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] 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 OUOzk1t3d-C8 for ; Mon, 25 Mar 2013 07:44:36 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D515011E80BA for ; Mon, 25 Mar 2013 07:44:35 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 16B7A22E259; Mon, 25 Mar 2013 10:44:28 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: Date: Mon, 25 Mar 2013 08:44:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <29A9BB7B-8F5A-46DF-8648-5F73CFD57FC4@iii.ca> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <5126925E.2010102@alum.mit.edu> <51296D15.1030105@alum.mit.edu> <51348999.1000506@gmail.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1503) Cc: dispatch@ietf.org, stephane.cazeaux@orange.com Subject: Re: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 14:44:37 -0000 On Mar 10, 2013, at 5:38 PM, I=F1aki Baz Castillo wrote: > 2013/3/10 Cullen Jennings : >> If an offer such s that got passed into a browser and it died, I = would view that as a bug. Of course I don' expect it to implement BFCP = but I expect the newer to correctly reject it. Actually, if there was = any string you could pass in from JS to the browser that caused the = browser to die, I would consider that a bug. >=20 > Probably it's a bug as you say. But my question is: will browser > vendors allow passing "strange" stuff into the SDP? Taking into > account the SDP format complexity and the issues already being > discussed rigth now in rtcweb WG about SDP usage, I don't expect that > such an exotic SDP will work. >=20 I would not describe this as exotic SDP - it's offer / answer SDP. Try = it out in firefox and see what happens.=20 From rlb@ipv.sx Mon Mar 25 14:44:05 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E6E21F8653 for ; Mon, 25 Mar 2013 14:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 F+ig0t0Kifv9 for ; Mon, 25 Mar 2013 14:44:05 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id BC86221F863B for ; Mon, 25 Mar 2013 14:44:04 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id ef5so3874080obb.13 for ; Mon, 25 Mar 2013 14:44:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TU9RDh+gz+W1eubKZTfTv+sVsVds7Twae/YzovpHzK0=; b=RFmKBJLvEFNtO7JwIaFLA2dj5WrhdI/euOTwG65LuxtE0GnoRl8hXJDz4+fEqhSepZ fF+WLKefEoegVUx2hIalBDDPhkNbFnHHJLgAiH9dPUiw6ZB/C1MtFRt2kiGuet0fFPFO 1athLQzW01NcieEvHtQK/yowMpvgny6wCiO0FSKuj39zBEPIcevVGFsomPWuWzbHZLT8 M0OGnstssLkwLoLDS4u2YYFzjVnWmu0Qjov0XW0jhu713OEgDuJx47FioEdO8ofjYorJ v2mgSEDBt75So3ns1Msm1vYhwk2GsI69bRU9HiwF7Cxpyud/CWeBuDD48I7jeM/eclev EXyg== MIME-Version: 1.0 X-Received: by 10.182.132.43 with SMTP id or11mr1036886obb.67.1364247844095; Mon, 25 Mar 2013 14:44:04 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Mon, 25 Mar 2013 14:44:03 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> Date: Mon, 25 Mar 2013 17:44:03 -0400 Message-ID: From: Richard Barnes To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=14dae93a0c17227bac04d8c6b4e8 X-Gm-Message-State: ALoCoQmxEd5KEqk1nn6gkUPkYFP/aZYKEYpZzORnxsYFFjTfe5d65tQfS6VNrQEoBtOJ/7S2wBVp Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 21:44:06 -0000 --14dae93a0c17227bac04d8c6b4e8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 14, 2013 at 10:30 AM, I=F1aki Baz Castillo wrot= e: > 2013/3/14 Paul Kyzivat : > > But I don't have javascript skills. I have heard variously that doing > such a > > binary protocol in javascript would be impossible, or just inconvenient= . > If > > it is just inconvenient, then a suitable library on top could fix that. > > I don't think so. The "issue" here is that JavaScript cannot properly > deal with binary information. This is, JS cannot get each "byte" of a > received string. Maybe there are some workarounds but, for sure, it > finally becomes painful. > I=F1aki: News of JavaScript's lack of binary access is highly overrated. There are efficient structures for binary access in most browsers today, based on Typed Arrays. People even do crypto with JS, arguably one of the applications most sensitive to which bits are where. Paul: Net of all that, I would say that reality is more on the "inconvenient" end of your spectrum. However, popping back up, WS and DataChannel APIs are essentially the same (by design), so what's defined for one should work over the other. --Richard > > Another JS library on top of the JS BPFC stack would not help a lot. > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --14dae93a0c17227bac04d8c6b4e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 14, 2013 at 10:30 AM, I=F1aki Baz Castillo &l= t;ibc@aliax.net><= /span> wrote:
2013/3/14 Paul Kyzivat <pkyziva= t@alum.mit.edu>:
> But I don't have javascript skills. I have heard= variously that doing such a
> binary protocol in javascript would be impossible, or just inconvenien= t. If
> it is just inconvenient, then a suitable library on top could fix that= .

I don't think so. The "issue" here is that JavaScript c= annot properly
deal with binary information. This is, JS cannot get each "byte" = of a
received string. Maybe there are some workarounds but, for sure, it
finally becomes painful.

I=F1aki:
=
News of JavaScript's lack of binary access is highly overrated. = =A0There are efficient structures for binary access in most browsers today,= based on Typed Arrays.
People even do crypto with JS, arguably one of the applications most sen= sitive to which bits are where.

Paul:
Net of= all that, I would say that reality is more on the "inconvenient"= end of your spectrum. =A0However, popping back up, WS and DataChannel APIs= are essentially the same (by design), so what's defined for one should= work over the other.

--Richard

=A0

Another JS library on top of the JS BPFC stack would not help a lot.


--
I=F1aki Baz Castillo
<ibc@aliax.net>
_____________________________= __________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--14dae93a0c17227bac04d8c6b4e8-- From ibc@aliax.net Mon Mar 25 15:20:27 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F201421F86F7 for ; Mon, 25 Mar 2013 15:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 NPWcsQrgEZYC for ; Mon, 25 Mar 2013 15:20:26 -0700 (PDT) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 37BF421F86EB for ; Mon, 25 Mar 2013 15:20:26 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id 1so3581026qee.30 for ; Mon, 25 Mar 2013 15:20:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=G2tBusMbRbqF5cx6nAMCF50j+sJvFAygyMqQ9Cg0DTs=; b=f6FGQ2b7mKxwrCp4IqB7NN6mXoQfzUy/WVE5m9Px62CsWvpPKqaQI9pwasxaicUXd9 BcY3NxjBUpZu1s6oxCI5OOnHtYP+2/hj+0ZG6gEQoy9HOz5OrWJB9Vyx47K5GrWw/Nxy kd9wwtdgcTWwnlDE5TnE9oqZZ4HgQ296t4h7S/Adlwh8vNmbLlYUenjjWD0NAK6JfYcN Pub6o/NovhyGhKOHX13K78JcmbEpwH6WZFzcFsVIvP/o0oPNX/Em4XFIChTjRTyFPPfj fymlcVQnddda5YSIpa0Geg1/pElWuLF05uLPhTH4nczlgs39+wIuPBkrNDVFLrdSZEDM wS0Q== X-Received: by 10.224.173.65 with SMTP id o1mr1380235qaz.83.1364250025644; Mon, 25 Mar 2013 15:20:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.64.138 with HTTP; Mon, 25 Mar 2013 15:20:05 -0700 (PDT) In-Reply-To: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 25 Mar 2013 23:20:05 +0100 Message-ID: To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkTLLqqdbeWvq/2Ix/DZO3p9lX5foa3JyGyhMs2W+raIKohznhDGaJoukHmJEZ2PiuRghiq Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 22:20:27 -0000 2013/3/25 Richard Barnes : > I=C3=B1aki: > News of JavaScript's lack of binary access is highly overrated. There ar= e > efficient structures for binary access in most browsers today, based on > Typed Arrays. > > People even do crypto with JS, arguably one of the applications most > sensitive to which bits are where. > Sure, but I wouldn't like to code a JS library to handle a binary protocol which could also have a text representation, much more suitable and friendly for a JS environment. This is not cryptography but a network protocol. IMHO a text based representation of the protocol should be needed. Regards. --=20 I=C3=B1aki Baz Castillo From sergio.garcia.murillo@gmail.com Mon Mar 25 15:21:51 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DCC21F892D for ; Mon, 25 Mar 2013 15:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] 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 5XsSpFEx8Wj1 for ; Mon, 25 Mar 2013 15:21:50 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFC021F8934 for ; Mon, 25 Mar 2013 15:21:42 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so2773927wiw.2 for ; Mon, 25 Mar 2013 15:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sF+UkYhm9N7ddHe2G7IhkiHofTukhnsrMCsQ9iSHr6c=; b=fwsyAg3qHXDURwPb8awr/50D2eL7jizogG8ziN5E4HjKUX3s7FS8cKZuMrK5W3o+Qn wk7xVetpKWbWlEOIvPxwHplGNR4e4oXTB+EL1v3Mj8ax8nOYJuOqwI3nA1CsA/uQ7KPP cmrT7QGwxy+UAw+ebXE158oIG58ijAX4qrv1PGpq1NBSEutAX9c+XiXLCuMcYAZ7NsCZ 6iRlSs+8t1HUqYTvGeTNte6KDShKT25ZEMvgtSDLjQ/7MvkwQMybmbIKFMD2tjOzaJeM Fe6EO+yHRLCfPVIN4EJb7LowRNX43cH27ezNAS4zNL8RKw+WWWfGjT4RQdkJeCJ/D2JS PVbA== X-Received: by 10.180.37.146 with SMTP id y18mr28701351wij.10.1364250102135; Mon, 25 Mar 2013 15:21:42 -0700 (PDT) Received: from [192.168.1.2] ([85.48.237.92]) by mx.google.com with ESMTPS id dp5sm30712444wib.1.2013.03.25.15.21.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 15:21:41 -0700 (PDT) Message-ID: <5150CDF4.6070007@gmail.com> Date: Mon, 25 Mar 2013 23:21:40 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 22:21:51 -0000 El 25/03/2013 23:20, Iñaki Baz Castillo escribió: > 2013/3/25 Richard Barnes : >> Iñaki: >> News of JavaScript's lack of binary access is highly overrated. There are >> efficient structures for binary access in most browsers today, based on >> Typed Arrays. >> >> People even do crypto with JS, arguably one of the applications most >> sensitive to which bits are where. >> > Sure, but I wouldn't like to code a JS library to handle a binary > protocol which could also have a text representation, much more > suitable and friendly for a JS environment. This is not cryptography > but a network protocol. IMHO a text based representation of the > protocol should be needed. +1 Best regards Sergio From pkyzivat@alum.mit.edu Mon Mar 25 16:19:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6F421F8585 for ; Mon, 25 Mar 2013 16:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 d989dy3Wo9DI for ; Mon, 25 Mar 2013 16:19:51 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 88FCF21F8581 for ; Mon, 25 Mar 2013 16:19:51 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id Flhc1l0051wpRvQ55zKrd0; Mon, 25 Mar 2013 23:19:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id FzKq1l00l3ZTu2S3ezKqP1; Mon, 25 Mar 2013 23:19:50 +0000 Message-ID: <5150DB96.5040201@alum.mit.edu> Date: Tue, 26 Mar 2013 07:19:50 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Richard Barnes References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364253591; bh=olVwUGgQeEhLpWs7xG7n/oO8MaQdlZI3SSGHyEGwdpw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=h1UeDAi/ql1YBzuLZcrhcAGK+beeZvcrODRnN99h1G2k8HpWupu4DE064GkiL2qqG HUAfWmBOdvxgUh9pUcW9NjPnRlf45eDtPjXdwbiJJPqz/8g9Cr44Cmpc0qaBrqJAlV 5m8027px/0xvtpP590HHnGcLETOnC87Tdq+To+MrX8vAw2XDJ3kyGEJZb/5bXMasxR cDjprCAiZOQfNWTAyIqWZi/Br7kMX4iWp1UGF3mFx6/RRVy+rAy/RBhx5j6tU7Mv1a +ZZBCYAdTz4lGBQ+zafiq2TfnKaLAMNg8ooXPFG7sQw2MD4k3uUPG+9R/6Cjzi2MzL oRNlVICCOCSJQ== Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 23:19:53 -0000 Richard, On 3/26/13 5:44 AM, Richard Barnes wrote: > On Thu, Mar 14, 2013 at 10:30 AM, Iñaki Baz Castillo > wrote: > > 2013/3/14 Paul Kyzivat >: > > But I don't have javascript skills. I have heard variously that > doing such a > > binary protocol in javascript would be impossible, or just > inconvenient. If > > it is just inconvenient, then a suitable library on top could fix > that. > > I don't think so. The "issue" here is that JavaScript cannot properly > deal with binary information. This is, JS cannot get each "byte" of a > received string. Maybe there are some workarounds but, for sure, it > finally becomes painful. > > > Iñaki: > News of JavaScript's lack of binary access is highly overrated. There > are efficient structures for binary access in most browsers today, based > on Typed Arrays. > > People even do crypto with JS, arguably one of the applications most > sensitive to which bits are where. > > > Paul: > Net of all that, I would say that reality is more on the "inconvenient" > end of your spectrum. Great. That is what I was hoping to hear. > However, popping back up, WS and DataChannel APIs > are essentially the same (by design), so what's defined for one should > work over the other. Yes, I understand that should be the case. But from a deployment perspective it makes quite a bit of difference which one(s) are actually deployed. Signaling in SDP that you can do it either way is incredibly messy, so I don't expect to see that. Practically speaking, bfcp over websocket will probably close the door on bfcp over data channel. So I think it is important to carefully consider which one to pursue. ISTM the main issue is that bfcp over datachannel can work peer to peer, while bfcp over websocket will only be useful with a webserver in the middle. (Presumably that can be resolved in some cases by inserting a websocket relay of some sort.) Thanks, Paul Thanks, Paul From mary.ietf.barnes@gmail.com Mon Mar 25 18:42:15 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF5E21F84D6 for ; Mon, 25 Mar 2013 18:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 E292keTeUq+f for ; Mon, 25 Mar 2013 18:42:14 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 627B721F84E0 for ; Mon, 25 Mar 2013 18:42:14 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id l8so19290qaq.15 for ; Mon, 25 Mar 2013 18:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=NyHOuydRy3kTIpY9YZEJpqOhvhJMPlaalNkWJsZExRI=; b=LFs4tdz/zr9SPmB0ZOE+rPC7HC+5PgSQTZL3vA7IevGPUjU5kNykuVQeiZ5bj12efM SEECMIJpjTDpQOrTG7mZzOdzY7ENSB4+DPCHnMebBeLXeHIajp9KPoD7d/Xek0sr6USU kddZc63t+AgoErNDCKMs2T07zSUZD1344P8ebYWgj3xU4QfVn2mV6anNw+bN6yFX1to6 1xsiJBUnxqr/FIcMS86por0euxTfsH3Vi9MD2uJGrvYZ6S7dKVUHvSpI/ZIxlUXXv6sX jXxj545xt7LmC4zYTY8MJfaOHEb6sOw7NQ7CbtoOgePSyApFgYkMcx0Rdlrdenxb+aoI 7B/Q== MIME-Version: 1.0 X-Received: by 10.224.168.6 with SMTP id s6mr4089520qay.63.1364262133868; Mon, 25 Mar 2013 18:42:13 -0700 (PDT) Received: by 10.49.94.166 with HTTP; Mon, 25 Mar 2013 18:42:13 -0700 (PDT) In-Reply-To: <5150DB96.5040201@alum.mit.edu> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> Date: Mon, 25 Mar 2013 20:42:13 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 01:42:15 -0000 On Mon, Mar 25, 2013 at 6:19 PM, Paul Kyzivat wrote= : > Richard, > > > On 3/26/13 5:44 AM, Richard Barnes wrote: >> >> On Thu, Mar 14, 2013 at 10:30 AM, I=F1aki Baz Castillo > > wrote: >> >> 2013/3/14 Paul Kyzivat > >: >> >> > But I don't have javascript skills. I have heard variously that >> doing such a >> > binary protocol in javascript would be impossible, or just >> inconvenient. If >> > it is just inconvenient, then a suitable library on top could fix >> that. >> >> I don't think so. The "issue" here is that JavaScript cannot properl= y >> deal with binary information. This is, JS cannot get each "byte" of = a >> received string. Maybe there are some workarounds but, for sure, it >> finally becomes painful. >> >> >> I=F1aki: >> News of JavaScript's lack of binary access is highly overrated. There >> are efficient structures for binary access in most browsers today, based >> on Typed Arrays. >> >> People even do crypto with JS, arguably one of the applications most >> sensitive to which bits are where. >> >> >> Paul: >> Net of all that, I would say that reality is more on the "inconvenient" >> end of your spectrum. > > > Great. That is what I was hoping to hear. > > >> However, popping back up, WS and DataChannel APIs >> are essentially the same (by design), so what's defined for one should >> work over the other. > > > Yes, I understand that should be the case. But from a deployment perspect= ive > it makes quite a bit of difference which one(s) are actually deployed. > Signaling in SDP that you can do it either way is incredibly messy, so I > don't expect to see that. > > Practically speaking, bfcp over websocket will probably close the door on > bfcp over data channel. [MB] Why specifically do you think this? [/MB] > So I think it is important to carefully consider > which one to pursue. > > ISTM the main issue is that bfcp over datachannel can work peer to peer, > while bfcp over websocket will only be useful with a webserver in the > middle. (Presumably that can be resolved in some cases by inserting a > websocket relay of some sort.) > > Thanks, > Paul > > Thanks, > Paul > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From gsalguei@cisco.com Mon Mar 25 19:33:24 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973A921F888E for ; Mon, 25 Mar 2013 19:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 I04c5ZTUJBX9 for ; Mon, 25 Mar 2013 19:33:23 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id AE27F21F8837 for ; Mon, 25 Mar 2013 19:33:23 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2Q2XNm7011418 for ; Mon, 25 Mar 2013 22:33:23 -0400 (EDT) Received: from rtp-gsalguei-8915.cisco.com (rtp-gsalguei-8915.cisco.com [10.116.132.54]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r2Q2XLxa006852; Mon, 25 Mar 2013 22:33:21 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Gonzalo Salgueiro In-Reply-To: Date: Mon, 25 Mar 2013 22:33:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <04781837-FC50-47CB-8183-7AFD68D427EA@cisco.com> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> To: Mary Barnes X-Mailer: Apple Mail (2.1503) Cc: DISPATCH Subject: Re: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 02:33:24 -0000 On Mar 25, 2013, at 9:42 PM, Mary Barnes = wrote: > On Mon, Mar 25, 2013 at 6:19 PM, Paul Kyzivat = wrote: >> Richard, >>=20 >>=20 >> On 3/26/13 5:44 AM, Richard Barnes wrote: >>>=20 >>> On Thu, Mar 14, 2013 at 10:30 AM, I=F1aki Baz Castillo = >> > wrote: >>>=20 >>> 2013/3/14 Paul Kyzivat >> >: >>>=20 >>>> But I don't have javascript skills. I have heard variously that >>> doing such a >>>> binary protocol in javascript would be impossible, or just >>> inconvenient. If >>>> it is just inconvenient, then a suitable library on top could fix >>> that. >>>=20 >>> I don't think so. The "issue" here is that JavaScript cannot = properly >>> deal with binary information. This is, JS cannot get each "byte" = of a >>> received string. Maybe there are some workarounds but, for sure, = it >>> finally becomes painful. >>>=20 >>>=20 >>> I=F1aki: >>> News of JavaScript's lack of binary access is highly overrated. = There >>> are efficient structures for binary access in most browsers today, = based >>> on Typed Arrays. >>> >>> People even do crypto with JS, arguably one of the applications most >>> sensitive to which bits are where. >>> >>>=20 >>> Paul: >>> Net of all that, I would say that reality is more on the = "inconvenient" >>> end of your spectrum. >>=20 >>=20 >> Great. That is what I was hoping to hear. >>=20 >>=20 >>> However, popping back up, WS and DataChannel APIs >>> are essentially the same (by design), so what's defined for one = should >>> work over the other. >>=20 >>=20 >> Yes, I understand that should be the case. But from a deployment = perspective >> it makes quite a bit of difference which one(s) are actually = deployed. >> Signaling in SDP that you can do it either way is incredibly messy, = so I >> don't expect to see that. >>=20 >> Practically speaking, bfcp over websocket will probably close the = door on >> bfcp over data channel. > [MB] Why specifically do you think this? [/MB] I'll go a bit further and say that I think that the BFCP over Websocket = IMO is useful and worth pursuing irrespective of whether BFCP over data = channel is standardized or not. I see no reason why these must mutually = exclude. Gonzalo =20 >> So I think it is important to carefully consider >> which one to pursue. >>=20 >> ISTM the main issue is that bfcp over datachannel can work peer to = peer, >> while bfcp over websocket will only be useful with a webserver in the >> middle. (Presumably that can be resolved in some cases by inserting a >> websocket relay of some sort.) >>=20 >> Thanks, >> Paul >>=20 >> Thanks, >> Paul >>=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 >=20 From ibc@aliax.net Tue Mar 26 02:07:44 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF8521F8457 for ; Tue, 26 Mar 2013 02:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 kEMna+aSVZZD for ; Tue, 26 Mar 2013 02:07:44 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id DCCA821F84E7 for ; Tue, 26 Mar 2013 02:07:43 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id k4so133874qaq.19 for ; Tue, 26 Mar 2013 02:07:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=sU0u8OGplHL9GIBGrdrrZDGYkEIBcW5xULfesQzFnkM=; b=iw/trEM+mSP16583O9+otSVfb1EM1A7Wu4nkgPSXC8vlG0MzOLVsntF9H6qbppRgDx rOVAU1uqOJFDNauCMaTLWyUO5nGqjvj/HOooDFfkztHvbKRRV4wKLLsTZ2u93VUERYgH 0mYQBLy3g/ACsE7csqoQrZBDpfSzUckIh+MNoukiv96bFmoQkJZeCa+gBxCOH7BEimKW Q3UZFNskVR5NCdsnn2qPC6wDcNf0aFpBcgRJjD92a/Sf4gHHe0K+H9B083fooiXPTFlt Tw3BGLBRdqiDlboZFguM0+4HmPmwXoAgJi0Oo1gL07FxOe5qMkbKcSG/vfuBkvlqIB2k /uog== X-Received: by 10.224.181.69 with SMTP id bx5mr5184300qab.95.1364288862271; Tue, 26 Mar 2013 02:07:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.64.138 with HTTP; Tue, 26 Mar 2013 02:07:22 -0700 (PDT) In-Reply-To: <5150DB96.5040201@alum.mit.edu> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 26 Mar 2013 10:07:22 +0100 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlnFEfXau98k5mDiWb/rjgxaI4eWVGiucjlo8L0ZCwZuyio5rhIQDpGtupDqzupUrkw4NCZ Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 09:07:44 -0000 2013/3/26 Paul Kyzivat : > ISTM the main issue is that bfcp over datachannel can work peer to peer, > while bfcp over websocket will only be useful with a webserver in the > middle. (Presumably that can be resolved in some cases by inserting a > websocket relay of some sort.) Hi Paul, which is the problem with having a relay server? This is WWW and not SIP physical devices with fixed code. In WWW world, clients (browsers) connect to a central server (the WWW server, which now can also be a WebSocket server) and signal with it. Honestly I don't like the idea of considering a JS application like a standalone SIP client which does not run in the context of a website, because that is not the way in which web apps work. So IMHO there is no advantage at all in having BFCP over data channel. In Web deployments the server wants to know about what happens in client side. I strongly discourage the vision of considering a JS application something like a "desktop softphone". It's not. Also, BFCP is a "signaling protocol", so let's say "a light protocol". It can be perfectly carried across central servers, there is no need at all for using client-to-client communication (this is not a media flow but a signaling flow). In short, I consider having MSRP over DataChannel something useful, but I consider that any other SIP related protocol (that does not involve carrying big data) should be implemented over WebSocket and never over DataChannel. And even more: using DataChannel for "signaling" breaks the WWW rules because here we are not in SIP land but in WWW land in which central servers exist and want to be in the path of the communications between clients. Best regards. --=20 I=C3=B1aki Baz Castillo From partha@parthasarathi.co.in Tue Mar 26 09:17:14 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F39F21F8BF4 for ; Tue, 26 Mar 2013 09:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 iHtMROaRSO6D for ; Tue, 26 Mar 2013 09:17:12 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.229]) by ietfa.amsl.com (Postfix) with ESMTP id D8E2221F8BEA for ; Tue, 26 Mar 2013 09:17:12 -0700 (PDT) Received: from userPC (unknown [122.172.183.222]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 60BE51EBFFEE; Tue, 26 Mar 2013 16:17:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1364314632; bh=th57Jh/uz64FCJma6ur8O6vYss6Dwws7L0j4mGtt0A4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=kalrB6mi1S+xQkLa1zOAvqC9rSbKO4kmjE8wZ9oNIXm2PpVCCwoCbYC4Ar9SRbJH+ v46N24H62lXs10kogzrCJuuGjE2CI+TkvE0OxI6SKpC6OXlIhLza1MdHCQ0HEd+Scg GkZ41H8BHW5NJJDAJDWoA+U028161gIvBIH4QDNU= From: "Parthasarathi R" To: =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= , "'Paul Kyzivat'" References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> In-Reply-To: Date: Tue, 26 Mar 2013 21:47:01 +0530 Message-ID: <001e01ce2a3d$5cee5d20$16cb1760$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4qAWW0nL6p7sC5RNKZCTs+ZaaXlAAOjPtw Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0209.5151CA08.0062, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 16:17:14 -0000 Hi all, I agree with Paul that BFCP over data channel is preferred because=20 BFCP is not related to SIP (focus) but it is more relevant to media=20 layer. Irrespective of signaling layer is SIP or HTTP, BFCP shall be=20 carried in media layer specific protocols (data channel) rather than=20 signaling layer specific protocol (WebSocket).=20 In case of the architecture wherein conferenence signaling entity (like SIP focus) is not physically co-located with RTP mixer, then RTP Mixer has no need to implement WebSocket for sake of supporting BFCP over WebSocket. Thanks Partha > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of I=C3=B1aki Baz Castillo > Sent: Tuesday, March 26, 2013 2:37 PM > To: Paul Kyzivat > Cc: dispatch@ietf.org > Subject: Re: [dispatch] FW: New Version Notification for = draft-pascual- > dispatch-bfcp-websocket-00.txt >=20 > 2013/3/26 Paul Kyzivat : > > ISTM the main issue is that bfcp over datachannel can work peer to > peer, > > while bfcp over websocket will only be useful with a webserver in = the > > middle. (Presumably that can be resolved in some cases by inserting = a > > websocket relay of some sort.) >=20 > Hi Paul, which is the problem with having a relay server? This is WWW > and not SIP physical devices with fixed code. In WWW world, clients > (browsers) connect to a central server (the WWW server, which now can > also be a WebSocket server) and signal with it. >=20 > Honestly I don't like the idea of considering a JS application like a > standalone SIP client which does not run in the context of a website, > because that is not the way in which web apps work. So IMHO there is > no advantage at all in having BFCP over data channel. In Web > deployments the server wants to know about what happens in client > side. I strongly discourage the vision of considering a JS application > something like a "desktop softphone". It's not. >=20 > Also, BFCP is a "signaling protocol", so let's say "a light protocol". > It can be perfectly carried across central servers, there is no need > at all for using client-to-client communication (this is not a media > flow but a signaling flow). >=20 >=20 > In short, I consider having MSRP over DataChannel something useful, > but I consider that any other SIP related protocol (that does not > involve carrying big data) should be implemented over WebSocket and > never over DataChannel. And even more: using DataChannel for > "signaling" breaks the WWW rules because here we are not in SIP land > but in WWW land in which central servers exist and want to be in the > path of the communications between clients. >=20 >=20 > Best regards. >=20 >=20 >=20 > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From ibc@aliax.net Tue Mar 26 09:39:10 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A033B21F8CA5 for ; Tue, 26 Mar 2013 09:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 rG1ftA-2K+K8 for ; Tue, 26 Mar 2013 09:39:08 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3F06921F8432 for ; Tue, 26 Mar 2013 09:39:06 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id b25so3257164qca.31 for ; Tue, 26 Mar 2013 09:39:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=CGtidrtRM4JzM84wOhEV8GNPf/292QDDhDYnIHugfUA=; b=nADCnmPbHtfyu0rKyfwZVDul30Vpy+cnwyEmYjt5e6NihbnpRX7/LeDfPI773nrxtN YXI57IKuayQcHEfim22YhJtjnN4CgT79bxS+mcYckMM3/OLTMTqEHZnW6PUB9KKMVVkV RS0tMIBD4ZOegld2r9ZjcMDgmwWaQxjnzbwfr3GQaoFxOyqQ1CWC9ZJ5k/wjqZ7vV+Z+ BH+EGwcZeJfsZ7CpQiE/nnr8WKQiE4lY6RTxXoEnWxxjE1Mc2A+XjoXsM+AZwwteBGV2 y/r+TtnCOzCgvEh0SZy4GnP0bs6LbptGmVIcF2kOKePl+xNr2myJxbGdyR5HZFDZIbeR 0vpA== X-Received: by 10.49.30.70 with SMTP id q6mr8911026qeh.28.1364315943366; Tue, 26 Mar 2013 09:39:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.64.138 with HTTP; Tue, 26 Mar 2013 09:38:43 -0700 (PDT) In-Reply-To: <001e01ce2a3d$5cee5d20$16cb1760$@co.in> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <001e01ce2a3d$5cee5d20$16cb1760$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 26 Mar 2013 17:38:43 +0100 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl9HH2RHgvPAK2MLRFXzA4VeDAv/u2g38ZXTip8wEM6pLfK7Wdo4aYXN3iPOtxwCzFwEaUB Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 16:39:11 -0000 2013/3/26 Parthasarathi R : > In case of the architecture wherein conferenence signaling entity > (like SIP focus) is not physically co-located with RTP mixer, then > RTP Mixer has no need to implement WebSocket for sake of supporting > BFCP over WebSocket. No, it just has to implement DataChannel, which is 100 times more difficult to implement than WebSocket. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Tue Mar 26 09:52:55 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537E621F84E0 for ; Tue, 26 Mar 2013 09:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.288 X-Spam-Level: X-Spam-Status: No, score=-0.288 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 8kpoxfIH4OcM for ; Tue, 26 Mar 2013 09:52:54 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id CDD2121F8BED for ; Tue, 26 Mar 2013 09:52:38 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta07.westchester.pa.mail.comcast.net with comcast id GGEK1l0020SCNGk57GsdgT; Tue, 26 Mar 2013 16:52:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id GGsd1l0193ZTu2S3VGsd9N; Tue, 26 Mar 2013 16:52:37 +0000 Message-ID: <5151D255.3050302@alum.mit.edu> Date: Wed, 27 Mar 2013 00:52:37 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Gonzalo Salgueiro References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <04781837-FC50-47CB-8183-7AFD68D427EA@cisco.com> In-Reply-To: <04781837-FC50-47CB-8183-7AFD68D427EA@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364316758; bh=+Vqw2Lb16fmmyhS3xTF4+CAHjss8FnSguy2FkMDSEPs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tTAuP/WmHGQjQQmNvW7AIGYE4ENiTmjKadL5idKCjuK5cYORbKWfocaVS6Ud/DUBv XsVLPodflM9MotyWQ5dxwHpwEAA8FFhyP8VPStUHqGq6piDce7Hz5KjzRWmY1ZZknc JmQZvXOQ2QwP3jz7JNr/8qBt/uFhFaHQe/9cXkmxUQwQfD2S2S0QfLSdaqPMJBJqoh Ak048KXQrRP95/F3z4uz59to7XN/6lL7/IGxiTpCHS1jvh5CRHEgHZamvF1h3z1bvN jjNgkf8JIa+BmtPVO3bFXtUU6LYJch1bjrbPH6WRJVY9iy1PMmWC1T0B13YyQ6EuFA 150eLI3CRpvMA== Cc: DISPATCH Subject: Re: [dispatch] New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 16:52:55 -0000 On 3/26/13 10:33 AM, Gonzalo Salgueiro wrote: >>>> However, popping back up, WS and DataChannel APIs >>>> are essentially the same (by design), so what's defined for one should >>>> work over the other. >>> >>> Yes, I understand that should be the case. But from a deployment perspective >>> it makes quite a bit of difference which one(s) are actually deployed. >>> Signaling in SDP that you can do it either way is incredibly messy, so I >>> don't expect to see that. >>> >>> Practically speaking, bfcp over websocket will probably close the door on >>> bfcp over data channel. >> [MB] Why specifically do you think this? [/MB] I question how many alternatives developers will implement. With bfcp over UDP there are two alternative. Adding websockets makes three, and also adding datachannels makes four. The more there are the lower the probability both ends will support a common one. And signaling support for more than one is difficult. This is already quite a problem with three, much less four. > I'll go a bit further and say that I think that the BFCP over Websocket IMO is useful and worth pursuing irrespective of whether BFCP over data channel is standardized or not. I see no reason why these must mutually exclude. Perhaps the only way this can really work is with a "relay/transcoder". A webserver hosting an WEBRTC client can insert such a thing to match the two sides. It will then "know" the WEBRTC client supports BFCP over websocket, and can then apply some knowledge of what the other end supports, within limits. If the other end is sip, then it may assume the choice is only BFCP over TCP or UDP and construct signaling for that. Bottom line: I think bfcp over websocket will probably preclude bfcp over data channel. (In a practical, not theoretical sense.) The converse is also probably true. But most likely a draft for bfcp over websocket can be completed sooner, and will fill many needs. In this case fewer is better. So I'll stop arguing about it. Thanks, Paul From ranjit.avasarala@nsn.com Tue Mar 26 10:06:58 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10A721F8C2A for ; Tue, 26 Mar 2013 10:06:58 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwz6HZP6wsEt for ; Tue, 26 Mar 2013 10:06:58 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8D20221F8BBD for ; Tue, 26 Mar 2013 10:06:57 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r2QH6pXC012920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Mar 2013 18:06:52 +0100 Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r2QH6nvm031438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Mar 2013 18:06:51 +0100 Received: from SGSIHTC003.nsn-intra.net (10.159.225.20) by SGSIHTC002.nsn-intra.net (10.159.225.19) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 27 Mar 2013 01:06:49 +0800 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.180]) by SGSIHTC003.nsn-intra.net ([10.159.225.20]) with mapi id 14.02.0328.009; Wed, 27 Mar 2013 01:06:49 +0800 From: "Avasarala, Ranjit (NSN - IN/Bangalore)" To: ext Parthasarathi R , =?utf-8?B?J0nDsWFraSBCYXogQ2FzdGlsbG8n?= , "'Paul Kyzivat'" Thread-Topic: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt Thread-Index: AQHOKj1omIsjwNEESUaBihJcMGDe2pi4M70w Date: Tue, 26 Mar 2013 17:06:48 +0000 Message-ID: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <001e01ce2a3d$5cee5d20$16cb1760$@co.in> In-Reply-To: <001e01ce2a3d$5cee5d20$16cb1760$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.112] X-TM-AS-Product-Ver: SMEX-10.0.0.4238-6.000.1038-15056.000 X-TM-AS-Result: No-1.113500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4894 X-purgate-ID: 151667::1364317612-00006A62-1C5CEE14/0-0/0-0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 17:06:58 -0000 UGFydGhhDQoNCkkgcmVhbGx5IGRvIG5vdCB0aGluayB0aGVyZSBjYW4gYmUgYSBTSVAgZm9jdXMg d2hpY2ggaXMganVzdCBzaWduYWxpbmcgZW50aXR5LCBpdCB3b3VsZCBhbHNvIGhhdmUgUlRQIG1p eGVyLiANCg0KUmVnYXJkcw0KUmFuaml0DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBQYXJ0aGFzYXJhdGhpIFINClNlbnQ6IFR1ZXNkYXks IE1hcmNoIDI2LCAyMDEzIDk6NDcgUE0NClRvOiAnScOxYWtpIEJheiBDYXN0aWxsbyc7ICdQYXVs IEt5eml2YXQnDQpDYzogZGlzcGF0Y2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hd IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBhc2N1YWwtZGlzcGF0Y2gt YmZjcC13ZWJzb2NrZXQtMDAudHh0DQoNCkhpIGFsbCwNCg0KSSBhZ3JlZSB3aXRoIFBhdWwgdGhh dCBCRkNQIG92ZXIgZGF0YSBjaGFubmVsIGlzIHByZWZlcnJlZCBiZWNhdXNlIA0KQkZDUCBpcyBu b3QgcmVsYXRlZCB0byBTSVAgKGZvY3VzKSBidXQgaXQgaXMgbW9yZSByZWxldmFudCB0byBtZWRp YSANCmxheWVyLiBJcnJlc3BlY3RpdmUgb2Ygc2lnbmFsaW5nIGxheWVyIGlzIFNJUCBvciBIVFRQ LCBCRkNQIHNoYWxsIGJlIA0KY2FycmllZCBpbiBtZWRpYSBsYXllciBzcGVjaWZpYyBwcm90b2Nv bHMgKGRhdGEgY2hhbm5lbCkgcmF0aGVyIHRoYW4gDQpzaWduYWxpbmcgbGF5ZXIgc3BlY2lmaWMg cHJvdG9jb2wgKFdlYlNvY2tldCkuIA0KDQpJbiBjYXNlIG9mIHRoZSBhcmNoaXRlY3R1cmUgd2hl cmVpbiBjb25mZXJlbmVuY2Ugc2lnbmFsaW5nIGVudGl0eQ0KKGxpa2UgU0lQIGZvY3VzKSBpcyBu b3QgcGh5c2ljYWxseSBjby1sb2NhdGVkIHdpdGggUlRQIG1peGVyLCB0aGVuDQpSVFAgTWl4ZXIg aGFzIG5vIG5lZWQgdG8gaW1wbGVtZW50IFdlYlNvY2tldCBmb3Igc2FrZSBvZiBzdXBwb3J0aW5n DQpCRkNQIG92ZXIgV2ViU29ja2V0Lg0KDQpUaGFua3MNClBhcnRoYQ0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgScOxYWtpIEJheiBD YXN0aWxsbw0KPiBTZW50OiBUdWVzZGF5LCBNYXJjaCAyNiwgMjAxMyAyOjM3IFBNDQo+IFRvOiBQ YXVsIEt5eml2YXQNCj4gQ2M6IGRpc3BhdGNoQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbZGlz cGF0Y2hdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBhc2N1YWwtDQo+ IGRpc3BhdGNoLWJmY3Atd2Vic29ja2V0LTAwLnR4dA0KPiANCj4gMjAxMy8zLzI2IFBhdWwgS3l6 aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PjoNCj4gPiBJU1RNIHRoZSBtYWluIGlzc3VlIGlz IHRoYXQgYmZjcCBvdmVyIGRhdGFjaGFubmVsIGNhbiB3b3JrIHBlZXIgdG8NCj4gcGVlciwNCj4g PiB3aGlsZSBiZmNwIG92ZXIgd2Vic29ja2V0IHdpbGwgb25seSBiZSB1c2VmdWwgd2l0aCBhIHdl YnNlcnZlciBpbiB0aGUNCj4gPiBtaWRkbGUuIChQcmVzdW1hYmx5IHRoYXQgY2FuIGJlIHJlc29s dmVkIGluIHNvbWUgY2FzZXMgYnkgaW5zZXJ0aW5nIGENCj4gPiB3ZWJzb2NrZXQgcmVsYXkgb2Yg c29tZSBzb3J0LikNCj4gDQo+IEhpIFBhdWwsIHdoaWNoIGlzIHRoZSBwcm9ibGVtIHdpdGggaGF2 aW5nIGEgcmVsYXkgc2VydmVyPyBUaGlzIGlzIFdXVw0KPiBhbmQgbm90IFNJUCBwaHlzaWNhbCBk ZXZpY2VzIHdpdGggZml4ZWQgY29kZS4gSW4gV1dXIHdvcmxkLCBjbGllbnRzDQo+IChicm93c2Vy cykgY29ubmVjdCB0byBhIGNlbnRyYWwgc2VydmVyICh0aGUgV1dXIHNlcnZlciwgd2hpY2ggbm93 IGNhbg0KPiBhbHNvIGJlIGEgV2ViU29ja2V0IHNlcnZlcikgYW5kIHNpZ25hbCB3aXRoIGl0Lg0K PiANCj4gSG9uZXN0bHkgSSBkb24ndCBsaWtlIHRoZSBpZGVhIG9mIGNvbnNpZGVyaW5nIGEgSlMg YXBwbGljYXRpb24gbGlrZSBhDQo+IHN0YW5kYWxvbmUgU0lQIGNsaWVudCB3aGljaCBkb2VzIG5v dCBydW4gaW4gdGhlIGNvbnRleHQgb2YgYSB3ZWJzaXRlLA0KPiBiZWNhdXNlIHRoYXQgaXMgbm90 IHRoZSB3YXkgaW4gd2hpY2ggd2ViIGFwcHMgd29yay4gU28gSU1ITyB0aGVyZSBpcw0KPiBubyBh ZHZhbnRhZ2UgYXQgYWxsIGluIGhhdmluZyBCRkNQIG92ZXIgZGF0YSBjaGFubmVsLiBJbiBXZWIN Cj4gZGVwbG95bWVudHMgdGhlIHNlcnZlciB3YW50cyB0byBrbm93IGFib3V0IHdoYXQgaGFwcGVu cyBpbiBjbGllbnQNCj4gc2lkZS4gSSBzdHJvbmdseSBkaXNjb3VyYWdlIHRoZSB2aXNpb24gb2Yg Y29uc2lkZXJpbmcgYSBKUyBhcHBsaWNhdGlvbg0KPiBzb21ldGhpbmcgbGlrZSBhICJkZXNrdG9w IHNvZnRwaG9uZSIuIEl0J3Mgbm90Lg0KPiANCj4gQWxzbywgQkZDUCBpcyBhICJzaWduYWxpbmcg cHJvdG9jb2wiLCBzbyBsZXQncyBzYXkgImEgbGlnaHQgcHJvdG9jb2wiLg0KPiBJdCBjYW4gYmUg cGVyZmVjdGx5IGNhcnJpZWQgYWNyb3NzIGNlbnRyYWwgc2VydmVycywgIHRoZXJlIGlzIG5vIG5l ZWQNCj4gYXQgYWxsIGZvciB1c2luZyBjbGllbnQtdG8tY2xpZW50IGNvbW11bmljYXRpb24gKHRo aXMgaXMgbm90IGEgbWVkaWENCj4gZmxvdyBidXQgYSBzaWduYWxpbmcgZmxvdykuDQo+IA0KPiAN Cj4gSW4gc2hvcnQsIEkgY29uc2lkZXIgaGF2aW5nIE1TUlAgb3ZlciBEYXRhQ2hhbm5lbCBzb21l dGhpbmcgdXNlZnVsLA0KPiBidXQgSSBjb25zaWRlciB0aGF0IGFueSBvdGhlciBTSVAgcmVsYXRl ZCBwcm90b2NvbCAodGhhdCBkb2VzIG5vdA0KPiBpbnZvbHZlIGNhcnJ5aW5nIGJpZyBkYXRhKSBz aG91bGQgYmUgaW1wbGVtZW50ZWQgb3ZlciBXZWJTb2NrZXQgYW5kDQo+IG5ldmVyIG92ZXIgRGF0 YUNoYW5uZWwuIEFuZCBldmVuIG1vcmU6IHVzaW5nIERhdGFDaGFubmVsIGZvcg0KPiAic2lnbmFs aW5nIiBicmVha3MgdGhlIFdXVyBydWxlcyBiZWNhdXNlIGhlcmUgd2UgYXJlIG5vdCBpbiBTSVAg bGFuZA0KPiBidXQgaW4gV1dXIGxhbmQgaW4gd2hpY2ggY2VudHJhbCBzZXJ2ZXJzIGV4aXN0IGFu ZCB3YW50IHRvIGJlIGluIHRoZQ0KPiBwYXRoIG9mIHRoZSBjb21tdW5pY2F0aW9ucyBiZXR3ZWVu IGNsaWVudHMuDQo+IA0KPiANCj4gQmVzdCByZWdhcmRzLg0KPiANCj4gDQo+IA0KPiAtLQ0KPiBJ w7Fha2kgQmF6IENhc3RpbGxvDQo+IDxpYmNAYWxpYXgubmV0Pg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QN Cj4gZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kaXNwYXRjaA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpkaXNwYXRjaEBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0K From pkyzivat@alum.mit.edu Tue Mar 26 10:24:57 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0021821F8A3F for ; Tue, 26 Mar 2013 10:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 CfO3Xajaqehg for ; Tue, 26 Mar 2013 10:24:56 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 4772721F850E for ; Tue, 26 Mar 2013 10:24:55 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta05.westchester.pa.mail.comcast.net with comcast id GBDu1l0060mv7h055HQuEd; Tue, 26 Mar 2013 17:24:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id GHQu1l00N3ZTu2S3XHQuh6; Tue, 26 Mar 2013 17:24:54 +0000 Message-ID: <5151D9E5.4090806@alum.mit.edu> Date: Wed, 27 Mar 2013 01:24:53 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364318694; bh=hIEBApeLQhX9llyQi59ejF45DoXXLNS8w6iIoQ5K96I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=j/g06XGvt3nPDzlRFny+3GfV+pmc5KJtoJW4uH8V4dY6bH4mG4NrqlGNDvRPUnPEN taCISampjKfENz17Z0AOfTHWNIxw0//p6cXw5qCqNFmGJUOpo/dTBNBEYCQ4BaWKog bVybZBr+Wv/tzboAAorEv8g7h58rHmqsqoMQv7qwwTl+PvrTmmEiEBbXg3R1/X4VPw 3cBKatyALOLWBJlSSv9xkeZ81TZBpBw8CMNt0BhHM0VKA4u4XnOxTMDLFX+v1GEkmd 1DaAJgi5o7gYfoG97CdDTbuFm7G4xsiyQ15d/pNs7oob2aViPbamJ/0e9oUgXqv4Yw Kuoa6EclowQ9g== Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 17:24:57 -0000 On 3/26/13 5:07 PM, Iñaki Baz Castillo wrote: > 2013/3/26 Paul Kyzivat : >> ISTM the main issue is that bfcp over datachannel can work peer to peer, >> while bfcp over websocket will only be useful with a webserver in the >> middle. (Presumably that can be resolved in some cases by inserting a >> websocket relay of some sort.) > > Hi Paul, which is the problem with having a relay server? This is WWW > and not SIP physical devices with fixed code. In WWW world, clients > (browsers) connect to a central server (the WWW server, which now can > also be a WebSocket server) and signal with it. > > Honestly I don't like the idea of considering a JS application like a > standalone SIP client which does not run in the context of a website, > because that is not the way in which web apps work. So IMHO there is > no advantage at all in having BFCP over data channel. In Web > deployments the server wants to know about what happens in client > side. I strongly discourage the vision of considering a JS application > something like a "desktop softphone". It's not. Your argument could also be applied to all the media. But the point of WEBRTC is to allow the media and the data channels to go e2e. > Also, BFCP is a "signaling protocol", so let's say "a light protocol". > It can be perfectly carried across central servers, there is no need > at all for using client-to-client communication (this is not a media > flow but a signaling flow). I realize that bfcp is likely to be a low data rate, and so its less of a problem for it to go indirectly via the server, but that only makes it less bad, it doesn't make it good. In general its bad to put something in the middle that doesn't need to be in the middle. > In short, I consider having MSRP over DataChannel something useful, > but I consider that any other SIP related protocol (that does not > involve carrying big data) should be implemented over WebSocket and > never over DataChannel. And even more: using DataChannel for > "signaling" breaks the WWW rules because here we are not in SIP land > but in WWW land in which central servers exist and want to be in the > path of the communications between clients. Why doesn't that argument apply to *everything* that might go over a data channel? But please see my earlier reply in this thread. I'm giving up. Thanks, Paul From rlb@ipv.sx Tue Mar 26 10:25:58 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8984121F8BF6 for ; Tue, 26 Mar 2013 10:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 lax2ejW4MDYE for ; Tue, 26 Mar 2013 10:25:57 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEA321F8C67 for ; Tue, 26 Mar 2013 10:25:56 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id k1so7834870oag.19 for ; Tue, 26 Mar 2013 10:25:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=xDw46AogXFxkS2Puqd4l9Ks3M6/MOCW6Ob3IeIRS5uE=; b=CpDA/vePRRWnk+2zpHCaP52EvJuKqCmQtx4hfiz0tMv1MPEpvK/eBfSu3Bo4bdTxhL Fml6J+b7AUZBT6Ou5LlHZSgx+30QErsXXzBCK+/Cqzp1qRKTSjYfegSfm9NLW/iAdFVN ZsxS5qyVQzdcOcldeNf/By90hRgDyCEFpzNvMW0sjE8iGljEuT7LGBS6EveX6vQMyr+N JAThbJfJdy2KygA5Z+5insHRZMbODa2tapEnWdDnJvF4Et0Rr6uEPa5Nddm1HTRL6WYu cV+N+yXTSQyIpaW2DpxSV3S9othUAuSs/P6JOI6yvrzEOiS5Djmod6k9BOHJeM7VJKkl Lt9g== MIME-Version: 1.0 X-Received: by 10.182.134.138 with SMTP id pk10mr2556126obb.80.1364318755943; Tue, 26 Mar 2013 10:25:55 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Tue, 26 Mar 2013 10:25:55 -0700 (PDT) X-Originating-IP: [192.1.255.184] In-Reply-To: References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <001e01ce2a3d$5cee5d20$16cb1760$@co.in> Date: Tue, 26 Mar 2013 13:25:55 -0400 Message-ID: From: Richard Barnes To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c29716cefe6404d8d7364b X-Gm-Message-State: ALoCoQk7nyEU29tj7C3aB/2gN8BUOrEH3Np2Epfk1kGyz+1xHBWdmZeKToqThcw7zytk29+q+5v/ Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 17:25:58 -0000 --001a11c29716cefe6404d8d7364b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It may be that implementing WS on the server side is easier than DataChannel. However, that's only because there are no libraries available right now. WS is not a dream to implement either, but there was enough interest and people built the libraries. There's enough interest in DataChannel that I wouldn't be surprised if the same thing happens. Thinking about the SDP a little further, however, it seems like DC is nicer from a WebRTC point of view, but WS is nicer from a backward-compatibility point of view. On the one hand: I don't think there's any expectation that a browser would implement BFCP, so it would have to be done in JS. That would mean that the JS would have to manipulate the SDP to add the BFCP offer, look for an answer, and possibly remove the answer before feeding the SDP back into the browser. It's not simple, but it's doable. DataChannel would be simpler for JS, since there's already a channel for JS to request data channels, without manipulating SDP. On the other hand: There's not really a good syntax for saying "this DataChannel stream will be used for BFCP". So adding WS as a transport for BFCP, on its own M-line, seems like a simpler way to allow for legacy interoperability. Legacy implementations would only have to add the WS transport for BFCP, as opposed to adding another layer of processing on top of SDP (i.e., identifying DataChannel streams). --Richard On Tue, Mar 26, 2013 at 12:38 PM, I=F1aki Baz Castillo wrot= e: > 2013/3/26 Parthasarathi R : > > In case of the architecture wherein conferenence signaling entity > > (like SIP focus) is not physically co-located with RTP mixer, then > > RTP Mixer has no need to implement WebSocket for sake of supporting > > BFCP over WebSocket. > > No, it just has to implement DataChannel, which is 100 times more > difficult to implement than WebSocket. > > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a11c29716cefe6404d8d7364b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It may be that implementing WS on the server side is easier than DataC= hannel. =A0However, that's only because there are no libraries availabl= e right now. =A0WS is not a dream to implement either, but there was enough= interest and people built the libraries. =A0There's enough interest in= DataChannel that I wouldn't be surprised if the same thing happens.

Thinking about the SDP a little further, however, it se= ems like DC is nicer from a WebRTC point of view, but WS is nicer from a ba= ckward-compatibility point of view.

On the one han= d: I don't think there's any expectation that a browser would imple= ment BFCP, so it would have to be done in JS. That would mean that =A0the J= S would have to manipulate the SDP to add the BFCP offer, look for an answe= r, and possibly remove the answer before feeding the SDP back into the brow= ser. =A0It's not simple, but it's doable. =A0DataChannel would be s= impler for JS, since there's already a channel for JS to request data c= hannels, without manipulating SDP.

On the other hand: There's not really a good syntax= for saying "this DataChannel stream will be used for BFCP". =A0S= o adding WS as a transport for BFCP, on its own M-line, seems like a simple= r way to allow for legacy interoperability. =A0Legacy implementations would= only have to add the WS transport for BFCP, as opposed to adding another l= ayer of processing on top of SDP (i.e., identifying DataChannel streams).

--Richard



On Tue, Mar 26, 2013 at 12:38 PM, I=F1aki Baz Castillo <ibc@a= liax.net> wrote:
2013/3/26 Parthasarathi R <partha@parthasarathi.co.in>:
> In case of the architecture wherein conferenence sig= naling entity
> (like SIP focus) is not physically co-located with RTP mixer, then
> RTP Mixer has no need to implement WebSocket for sake of supporting > BFCP over WebSocket.

No, it just has to implement DataChannel, which is 100 times more
difficult to implement than WebSocket.



--
I=F1aki Baz Castillo
<ibc@aliax.net>
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--001a11c29716cefe6404d8d7364b-- From ibc@aliax.net Tue Mar 26 10:28:56 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377A121F8BF4 for ; Tue, 26 Mar 2013 10:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 0aFTso1LBruB for ; Tue, 26 Mar 2013 10:28:55 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4821F8B45 for ; Tue, 26 Mar 2013 10:28:49 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id w7so2779123qeb.34 for ; Tue, 26 Mar 2013 10:28:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=4m5JriK90Gx+k02dC7WrGrpc+ls+P45Oms8Hp+hJ3XU=; b=BtivtpORidzDyP1BMeiXkEdFTipuvcsaOMKj2xEDP3xTo+Zp6Ey13kM/6royROYZH2 pFoiMitsHWneGZsVDfRIjUkn+9WkeNJQt669N4URBu6S/5NsfJcCk4bFXZtOIFDEzSAm 7R5oadpEuyQlc95lBU8KjI+b8bLB9hcuuZlN2zNDFsq5qOokU75RlkFTDSyL995aC1eC kZ5UDF2I1SL2sKpXI7kkvzwzJIY/a3cBQxIt7ccpqqxYw3iE6w1Aerwbp48HoCmjjdbZ 4GkhaP0FUuzglWaymh5ROeUm/aJmkL8UQozuvA1Rk9Sl2Jk6G0gdSmSWNag6SsxqzPfk +8Uw== X-Received: by 10.229.180.2 with SMTP id bs2mr3293995qcb.52.1364318928580; Tue, 26 Mar 2013 10:28:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.64.138 with HTTP; Tue, 26 Mar 2013 10:28:28 -0700 (PDT) In-Reply-To: <5151D9E5.4090806@alum.mit.edu> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <5151D9E5.4090806@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 26 Mar 2013 18:28:28 +0100 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnWEhGwH6Ax1hK5UoA8KNojLLaBjWHJ4vfZ46KrxRZUsOsy8E028T7OWyoYwWldiYpRXCMQ Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 17:28:56 -0000 Hi Paul, just some comments and let us give up this subject ;) >> Honestly I don't like the idea of considering a JS application like a >> standalone SIP client which does not run in the context of a website, >> because that is not the way in which web apps work. So IMHO there is >> no advantage at all in having BFCP over data channel. In Web >> deployments the server wants to know about what happens in client >> side. I strongly discourage the vision of considering a JS application >> something like a "desktop softphone". It's not. > > > Your argument could also be applied to all the media. > But the point of WEBRTC is to allow the media and the data channels to go > e2e. Right, but still WebRTC clients are web browsers which runs web applications. I expect that datachannel is good for file transfer, realtime info (i.e. games) between *browsers*. But having a server that speaks datachannel seems a bit "complex" IMHO. > In general its bad to put something in the middle that doesn't need to be= in > the middle. What I have in mind is that the WebSocket server is co-located in the conference focus. :) Regards. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Tue Mar 26 11:20:36 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF6221F8BED for ; Tue, 26 Mar 2013 11:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 mbFwlcROKXO3 for ; Tue, 26 Mar 2013 11:20:36 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id B7C7821F8BDE for ; Tue, 26 Mar 2013 11:20:35 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta09.westchester.pa.mail.comcast.net with comcast id GB4b1l0031wpRvQ59JLXxQ; Tue, 26 Mar 2013 18:20:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id GJLX1l0103ZTu2S3eJLXrM; Tue, 26 Mar 2013 18:20:31 +0000 Message-ID: <5151E6EE.4070305@alum.mit.edu> Date: Wed, 27 Mar 2013 02:20:30 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <001e01ce2a3d$5cee5d20$16cb1760$@co.in> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364322031; bh=OA3S1ehHykwLxe3fvp7sBc4I1Yg6KB+PkoPr8Nw5QKU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GNhWS9zu+NCJZQTFDlOE5juh2SLtPQ1HOOQ5sih+Yy9VYlBGJYs6maR3wXZXya/ck O/JNj8/LcPZpGpezKHc+xtdrHyoNCv0u0FRA7+94jXwxj/wXglrINtgQdGxlwLBiMg Md3/E9LLIOyOqpS2ofUIUeWZ3yUcs0ooAdTV4RMantyuOm1wV967IrxvcX8MO1ZiJN Wtuo/+Kb5fCTFrTLkKJtVATG8qHzt65zLVHIxHfmmjBryi1XDGiQCy12Raug2l7uK+ 3vp2sGohQhp7NVg3jP+YbzbS9GOxhFhVpf7tESwNFqD7BVnOkbJOz3U03/RAj5EvZE WdZnWaSZubFSg== Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 18:20:36 -0000 On 3/27/13 1:25 AM, Richard Barnes wrote: > On the other hand: There's not really a good syntax for saying "this > DataChannel stream will be used for BFCP". So adding WS as a transport > for BFCP, on its own M-line, seems like a simpler way to allow for > legacy interoperability. Legacy implementations would only have to add > the WS transport for BFCP, as opposed to adding another layer of > processing on top of SDP (i.e., identifying DataChannel streams). Hence my interest in the SCTP SDP proposal that *did* have a way to say "this DataChannel stream will be used for BFCP" (as well as saying "this other DataChannel will be used for CLUE".) But I can live without that for now. Thanks, Paul From pkyzivat@alum.mit.edu Tue Mar 26 11:32:12 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EEE21F8BA6 for ; Tue, 26 Mar 2013 11:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] 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 qOjIhkVhlL2M for ; Tue, 26 Mar 2013 11:32:11 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 6574521F8AF0 for ; Tue, 26 Mar 2013 11:32:11 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta01.westchester.pa.mail.comcast.net with comcast id GFbX1l0051c6gX851JY1aK; Tue, 26 Mar 2013 18:32:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id GJY11l00D3ZTu2S3jJY1qF; Tue, 26 Mar 2013 18:32:01 +0000 Message-ID: <5151E9A1.90002@alum.mit.edu> Date: Wed, 27 Mar 2013 02:32:01 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <5151D9E5.4090806@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364322721; bh=tUPEHPhX4WW/QRqLqYHuQtPeYoXuojQDWhSqdzxS7pI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ImY3A/PkXxEEZs53X8yau/+pjpBcUqkyyaj6aWlXnYK41ouk6vMl5b8oN3cGautI4 hPrPOgWClydSeAGLx5luMm09jY5nnnToIJwX4o8t5tCi62qSJnzo31Ljklql3YyDvl e7qowMZW4f0Uxj3ldwC3En29f0OdFuJJIclwrjmnaWdO2wENVAlZwOvwnJACYEZJhx FxZr4X4V5HTVhNN3p55vAz92hHG9rV+1r+r27ZgXp6f3udRb3yR4/XS4sZwU55hzBp kKwTiYRxzyJyDwiNuqfaZF/bZsG0tBNs6pMbku/vq/dKAYAoxHLMe1cnP9jsj++F0/ BvskRkmQtjQIg== Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 18:32:12 -0000 I think we have some different assumptions... On 3/27/13 1:28 AM, Iñaki Baz Castillo wrote: > Hi Paul, just some comments and let us give up this subject ;) > >>> Honestly I don't like the idea of considering a JS application like a >>> standalone SIP client which does not run in the context of a website, >>> because that is not the way in which web apps work. So IMHO there is >>> no advantage at all in having BFCP over data channel. In Web >>> deployments the server wants to know about what happens in client >>> side. I strongly discourage the vision of considering a JS application >>> something like a "desktop softphone". It's not. >> >> Your argument could also be applied to all the media. >> But the point of WEBRTC is to allow the media and the data channels to go >> e2e. > > Right, but still WebRTC clients are web browsers which runs web > applications. I expect that datachannel is good for file transfer, > realtime info (i.e. games) between *browsers*. But having a server > that speaks datachannel seems a bit "complex" IMHO. > >> In general its bad to put something in the middle that doesn't need to be in >> the middle. > > What I have in mind is that the WebSocket server is co-located in the > conference focus. :) You seem to be assuming a couple of things that I am not: - that we only care about bfcp with conferences, not p2p calls. - that the web server supporting a webrtc client is also the conference focus when there is a conference. I don't think either of those is true. Especially not the latter one. For instance, I can easily foresee a webserver that provides CLUE support to browsers - as a sort of enhanced functionality sip client. It would support establishing a session to any other sip UA and provide clue functionality whenever both ends support it. Sometimes the other end will be a clue conference focus. Sometimes it will be another clueful endpoint. If websocket support is required to support bfcp in this context, then the webrtc server will need to provide a websocket relay/gateway to connect to the other clue endpoint. Thanks, Paul From ibc@aliax.net Tue Mar 26 15:22:55 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7640E21F850C for ; Tue, 26 Mar 2013 15:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 5nlJ9g2IQIgV for ; Tue, 26 Mar 2013 15:22:55 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 950D821F8A08 for ; Tue, 26 Mar 2013 15:22:46 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id b25so3427600qca.3 for ; Tue, 26 Mar 2013 15:22:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=MjFgvV1naFyiY6Clv2iA8cMNrNMd24ly4yGcxkoXv3g=; b=f02qrmVBG1l+wrJseY3T6pjLw3c7MQNjQTqoC9UoDdlTyBqGlz1QcAX9cvg5GbjlsB 6B6QI12511vgVgIqomB9H36xWwkyeZOssbBk9zp2xjJcvPyrPZuaxEXA8QoWtTXl2MjV sopgBOzm57X2d8P7m2YU9BcG5kPL7fIlFerHTKTn3qb5yL+RMjLaIZan5f6vqA+jWHgt hysB+KkATlGhG5EvI1LWI73ZfLFqO6CYrtBRlF2N2u8Ou0c43qge6/SMyjaUWY0+WyOC NdXujCexWcvdk6JUAO9kZJTebN0qHo4mHisURgLJtE15MU5S/8aXHAnNTnbi4ayTt/NA eaMw== X-Received: by 10.224.173.65 with SMTP id o1mr6532322qaz.83.1364336559248; Tue, 26 Mar 2013 15:22:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.64.138 with HTTP; Tue, 26 Mar 2013 15:22:19 -0700 (PDT) In-Reply-To: <5151E9A1.90002@alum.mit.edu> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <5151D9E5.4090806@alum.mit.edu> <5151E9A1.90002@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 26 Mar 2013 23:22:19 +0100 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkMvv1SKzzYPnGtOacOQsTeg5rXdQHKgxbI753wQ/4W2X/Yp4yILN03i7uX2tLnGQDZfm61 Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 22:22:55 -0000 2013/3/26 Paul Kyzivat : > You seem to be assuming a couple of things that I am not: > > - that we only care about bfcp with conferences, not p2p calls. I must recognize that I don't know BFCP well enough. Not sure about what is the purpose of BFC in p2p calls. > - that the web server supporting a webrtc client is also the conference > focus when there is a conference. > > I don't think either of those is true. Especially not the latter one. For > instance, I can easily foresee a webserver that provides CLUE support to > browsers - as a sort of enhanced functionality sip client. It would suppo= rt > establishing a session to any other sip UA and provide clue functionality > whenever both ends support it. Sometimes the other end will be a clue > conference focus. Sometimes it will be another clueful endpoint. > > If websocket support is required to support bfcp in this context, then th= e > webrtc server will need to provide a websocket relay/gateway to connect t= o > the other clue endpoint. I understand your point. Just as a side note, nothing prevents a JS app running in a browser to make more than a single WebSocket connection against different servers (i.e. a WS connection with a SIP server and another WS connection with a BFCP server/relay/gateway. Regards. --=20 I=C3=B1aki Baz Castillo From sergio.garcia.murillo@gmail.com Tue Mar 26 15:39:35 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5FD21F8995 for ; Tue, 26 Mar 2013 15:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] 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 WPh2A9dhm5cR for ; Tue, 26 Mar 2013 15:39:35 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id E54A321F88C4 for ; Tue, 26 Mar 2013 15:39:34 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hm14so1710332wib.15 for ; Tue, 26 Mar 2013 15:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=86kr6kCc/9GZB4UwhBlXBN4f59AzFa3YQ3JJW8NhA/U=; b=StIm79sDM6+NV+aLnS0OiocY8lvilkGt733gW/Rr2tfDLEfHbEqmgjt6KUXRc2kXdZ xF5ctVov1YQjyNr5FozJGrC8RWudZqZkRqyfwB6EE7RmKn7t59qmQZi0t0Kg2Cd88O8H 9NTSLD4YdwlexIIxQNKOxWoKw4FHtff0r3ynSYhf8w0XoGAi6dltxIANZLzLSYGyh/1J BFbd4EsTb40dUPkSELneG05AdlZmcNTi2mwdKhSZJb9W8fzXNFaogP3/fpLUXq3NbRKa B7f6/SbwkaaO6HL3wmoBGD4SySrJjfhrXvki4/YCSFBiP2vbErTNn5vAsIs4pBRurIQW z6vw== X-Received: by 10.180.13.34 with SMTP id e2mr6102535wic.29.1364337574102; Tue, 26 Mar 2013 15:39:34 -0700 (PDT) Received: from [192.168.1.2] ([85.48.237.92]) by mx.google.com with ESMTPS id j4sm5549377wiz.10.2013.03.26.15.39.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Mar 2013 15:39:33 -0700 (PDT) Message-ID: <515223A5.7050209@gmail.com> Date: Tue, 26 Mar 2013 23:39:33 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <5151D9E5.4090806@alum.mit.edu> <5151E9A1.90002@alum.mit.edu> In-Reply-To: <5151E9A1.90002@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 22:39:35 -0000 El 26/03/2013 19:32, Paul Kyzivat escribió: > > You seem to be assuming a couple of things that I am not: > > - that we only care about bfcp with conferences, not p2p calls. While BFCP can be used in p2p calls, I don't think it is its main use case, from the RFC: Scope As stated earlier, BFCP is a protocol to coordinate access to shared resources in a conference following the requirements defined in [9]. Floor control complements other functions defined in the XCON conferencing framework [10]. Also, coordinating the access to a shared resource between two parties in which one of them has the ownership of the resource doesn't seem quite a big deal. > > - that the web server supporting a webrtc client is also the conference > focus when there is a conference. > > I don't think either of those is true. Especially not the latter one. > For instance, I can easily foresee a webserver that provides CLUE > support to browsers - as a sort of enhanced functionality sip client. > It would support establishing a session to any other sip UA and > provide clue functionality whenever both ends support it. Sometimes > the other end will be a clue conference focus. Sometimes it will be > another clueful endpoint. > > If websocket support is required to support bfcp in this context, then > the webrtc server will need to provide a websocket relay/gateway to > connect to the other clue endpoint. > Why it is needed that the web server is also the focus server? My MCU has different components for SIP handing and media mixing and web server for the web client HTML and it is order of magnitude implementing web sockets (even from scratch) than supporting datachannels at all. Best regards Sergio From eckelcu@cisco.com Tue Mar 26 16:12:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D9F21F8922 for ; Tue, 26 Mar 2013 16:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 hEHAWiD1enC4 for ; Tue, 26 Mar 2013 16:12:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A046221F86C4 for ; Tue, 26 Mar 2013 16:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4122; q=dns/txt; s=iport; t=1364339546; x=1365549146; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=p311yS5/Lb/ydXDo0eweknqmVwQv0unhqf99R/jRvxM=; b=L9vZBkxxnOkudKOc8ne1UIAb2IMZb9pMVD8DZxa+wGcdRr6H4Z/QwJD8 exJc+hBZuTQzYvdXy0Tx7QaH8wZP2IoAUK+d1Ll0s9I7vqT2Hqsf6Ch1Q fwm64eBtjoTUaNFgszzgxqOB3VOopB6OAwUIHIBohRTguiUwBGrZOEv6L I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8HADkqUlGtJV2a/2dsb2JhbABDgzqDHr1BDXoWgSqCHwEBAQQBAQEgETQGCQ4EAgEIEQQBAQMCBh0DAgICJQsUAQcBCAIEARIIiAsBDK1mgkCPaQSBI40+FhASBoInMmEDkyGUTYFVgTaCKA X-IronPort-AV: E=Sophos;i="4.84,915,1355097600"; d="scan'208";a="191791768" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 26 Mar 2013 23:12:26 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2QNCP4s030623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Mar 2013 23:12:25 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 26 Mar 2013 18:12:25 -0500 From: "Charles Eckel (eckelcu)" To: Sergio Garcia Murillo , "dispatch@ietf.org" Thread-Topic: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt Thread-Index: AQHOIGHVomgQZA0ZWUGWFhYfIrOzb5illCEAgBHCqICAABrDAIAApCgAgACLAYCAAAEAAIAAEcKAgABFKYD//7KdEA== Date: Tue, 26 Mar 2013 23:12:24 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047DD582@xmb-aln-x08.cisco.com> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <5151D9E5.4090806@alum.mit.edu> <5151E9A1.90002@alum.mit.edu> <515223A5.7050209@gmail.com> In-Reply-To: <515223A5.7050209@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 23:12:28 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkaXNwYXRjaC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9m IFNlcmdpbyBHYXJjaWEgTXVyaWxsbw0KPiBTZW50OiBUdWVzZGF5LCBNYXJjaCAyNiwgMjAxMyAz OjQwIFBNDQo+IFRvOiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2Rpc3BhdGNo XSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1wYXNjdWFsLQ0KPiBkaXNw YXRjaC1iZmNwLXdlYnNvY2tldC0wMC50eHQNCj4gDQo+IEVsIDI2LzAzLzIwMTMgMTk6MzIsIFBh dWwgS3l6aXZhdCBlc2NyaWJpw7M6DQo+ID4NCj4gPiBZb3Ugc2VlbSB0byBiZSBhc3N1bWluZyBh IGNvdXBsZSBvZiB0aGluZ3MgdGhhdCBJIGFtIG5vdDoNCj4gPg0KPiA+IC0gdGhhdCB3ZSBvbmx5 IGNhcmUgYWJvdXQgYmZjcCB3aXRoIGNvbmZlcmVuY2VzLCBub3QgcDJwIGNhbGxzLg0KPiANCj4g V2hpbGUgQkZDUCBjYW4gYmUgdXNlZCBpbiBwMnAgY2FsbHMsIEkgZG9uJ3QgdGhpbmsgaXQgaXMg aXRzIG1haW4gdXNlDQo+IGNhc2UsIGZyb20gdGhlIFJGQzoNCj4gDQo+IFNjb3BlDQo+IA0KPiAg ICAgQXMgc3RhdGVkIGVhcmxpZXIsIEJGQ1AgaXMgYSBwcm90b2NvbCB0byBjb29yZGluYXRlIGFj Y2VzcyB0byBzaGFyZWQNCj4gICAgIHJlc291cmNlcyBpbiBhIGNvbmZlcmVuY2UgZm9sbG93aW5n IHRoZSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbiBbOV0uDQo+ICAgICBGbG9vciBjb250cm9sIGNv bXBsZW1lbnRzIG90aGVyIGZ1bmN0aW9ucyBkZWZpbmVkIGluIHRoZSBYQ09ODQo+ICAgICBjb25m ZXJlbmNpbmcgZnJhbWV3b3JrIFsxMF0uDQo+IA0KPiANCj4gQWxzbywgY29vcmRpbmF0aW5nIHRo ZSBhY2Nlc3MgdG8gYSBzaGFyZWQgcmVzb3VyY2UgYmV0d2VlbiB0d28gcGFydGllcw0KPiBpbiB3 aGljaCBvbmUgb2YgdGhlbSBoYXMgdGhlIG93bmVyc2hpcCBvZiB0aGUgcmVzb3VyY2UgZG9lc24n dCBzZWVtDQo+IHF1aXRlIGEgYmlnIGRlYWwuDQoNCkkgYWdyZWUgdGhhdCBjb29yZGluYXRpb24g YmV0d2VlbiB0d28gcGFydGllcyBpcyBlYXNpZXIgdGhhbiBhbW9uZyBtYW55IHBhcnRpZXMuIFRo YXQgc2FpZCwgd2l0aCBTSVAgYmFzZWQgdmlkZW8gY29uZmVyZW5jaW5nIGltcGxlbWVudGF0aW9u cywgdGhlIHNhbWUgY29vcmRpbmF0aW9uIGlzIHVzZWQgZm9yIGJvdGggY2FzZXMuIFRoZSBkZXRl cm1pbmF0aW9uIG9mIHdoaWNoIHNpZGUgb3ducyB3aGljaCByZXNvdXJjZSBpcyB2aWEgU0RQLCBh bmQgdGhlIHJlYWwtdGltZSByZXF1ZXN0IGFuZCBncmFudGluZyBvZiB0aGUgcmVzb3VyY2UgaXMg dmlhIEJGQ1AuIEZvciBzZXNzaW9ucyBiZXR3ZWVuIGFuIGVuZHBvaW50IGFuZCBhIGNvbmZlcmVu Y2UgZm9jdXMsIHRoZSBjb25mZXJlbmNlIGZvY3VzIHR5cGljYWxseSByZXF1aXJlcyB0aGF0IGl0 IGJlIHRoZSBvd25lciBvZiB0aGUgY29udGVudCBzaGFyaW5nIHJlc291cmNlLiBGb3IgcG9pbnQg dG8gcG9pbnQgY2FsbHMsIGl0IGNvdWxkIGJlIGVpdGhlciBlbmRwb2ludCBhc3N1bWluZyB0aGlz IHJvbGUuIFRoaXMgd2F5IHRoZSBzYW1lIFNEUCBuZWdvdGlhdGlvbiBhbmQgQkZDUCBtZXNzYWdp bmcgaXMgdXNlZCBjb25zaXN0ZW50bHkgZm9yIGJvdGggY29uZmVyZW5jZSBhbmQgcG9pbnQgdG8g cG9pbnQgY2FsbHMuDQoNCkNoZWVycywNCkNoYXJsZXMNCg0KPiA+DQo+ID4gLSB0aGF0IHRoZSB3 ZWIgc2VydmVyIHN1cHBvcnRpbmcgYSB3ZWJydGMgY2xpZW50IGlzIGFsc28gdGhlIGNvbmZlcmVu Y2UNCj4gPiAgIGZvY3VzIHdoZW4gdGhlcmUgaXMgYSBjb25mZXJlbmNlLg0KPiA+DQo+ID4gSSBk b24ndCB0aGluayBlaXRoZXIgb2YgdGhvc2UgaXMgdHJ1ZS4gRXNwZWNpYWxseSBub3QgdGhlIGxh dHRlciBvbmUuDQo+ID4gRm9yIGluc3RhbmNlLCBJIGNhbiBlYXNpbHkgZm9yZXNlZSBhIHdlYnNl cnZlciB0aGF0IHByb3ZpZGVzIENMVUUNCj4gPiBzdXBwb3J0IHRvIGJyb3dzZXJzIC0gYXMgYSBz b3J0IG9mIGVuaGFuY2VkIGZ1bmN0aW9uYWxpdHkgc2lwIGNsaWVudC4NCj4gPiBJdCB3b3VsZCBz dXBwb3J0IGVzdGFibGlzaGluZyBhIHNlc3Npb24gdG8gYW55IG90aGVyIHNpcCBVQSBhbmQNCj4g PiBwcm92aWRlIGNsdWUgZnVuY3Rpb25hbGl0eSB3aGVuZXZlciBib3RoIGVuZHMgc3VwcG9ydCBp dC4gU29tZXRpbWVzDQo+ID4gdGhlIG90aGVyIGVuZCB3aWxsIGJlIGEgY2x1ZSBjb25mZXJlbmNl IGZvY3VzLiBTb21ldGltZXMgaXQgd2lsbCBiZQ0KPiA+IGFub3RoZXIgY2x1ZWZ1bCBlbmRwb2lu dC4NCj4gPg0KPiA+IElmIHdlYnNvY2tldCBzdXBwb3J0IGlzIHJlcXVpcmVkIHRvIHN1cHBvcnQg YmZjcCBpbiB0aGlzIGNvbnRleHQsIHRoZW4NCj4gPiB0aGUgd2VicnRjIHNlcnZlciB3aWxsIG5l ZWQgdG8gcHJvdmlkZSBhIHdlYnNvY2tldCByZWxheS9nYXRld2F5IHRvDQo+ID4gY29ubmVjdCB0 byB0aGUgb3RoZXIgY2x1ZSBlbmRwb2ludC4NCj4gPg0KPiANCj4gV2h5IGl0IGlzIG5lZWRlZCB0 aGF0IHRoZSB3ZWIgc2VydmVyIGlzIGFsc28gdGhlIGZvY3VzIHNlcnZlcj8gTXkgTUNVDQo+IGhh cyBkaWZmZXJlbnQgY29tcG9uZW50cyBmb3IgU0lQIGhhbmRpbmcgYW5kIG1lZGlhIG1peGluZyBh bmQgd2ViIHNlcnZlcg0KPiBmb3IgdGhlIHdlYiBjbGllbnQgSFRNTCBhbmQgaXQgaXMgb3JkZXIg b2YgbWFnbml0dWRlIGltcGxlbWVudGluZyB3ZWINCj4gc29ja2V0cyAoZXZlbiBmcm9tIHNjcmF0 Y2gpIHRoYW4gc3VwcG9ydGluZyBkYXRhY2hhbm5lbHMgYXQgYWxsLg0KPiANCj4gQmVzdCByZWdh cmRzDQo+IFNlcmdpbw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gZGlzcGF0Y2hAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0K From sergio.garcia.murillo@gmail.com Tue Mar 26 16:28:43 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E5D21F89AA for ; Tue, 26 Mar 2013 16:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] 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 hS9-xZqbyFhz for ; Tue, 26 Mar 2013 16:28:42 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 402BB21F894D for ; Tue, 26 Mar 2013 16:28:42 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id s43so2492459wey.21 for ; Tue, 26 Mar 2013 16:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GgY1B3pjnL1KJJJirDLUkYjj/JYs/k14lVMlQ77g6Zk=; b=0SX2z857b07sjzEVhtrkJFzQhhRICdjIWyw99vrHqWtS6voYfq7w0g9+hPCOLIXly4 egBGPCLGP6i5PqZICDqBou10snd6NJXPsIdAxMYmk7pG/lE8ePSQE8lbtg0wVGJRLnqC gbZOqxQg5zo980wnZU48iwMIJhx7Ooif+HsjjLwlnWEnPSfj9xEi7hbVoudbggGSWgp3 SB5rTCpuutTJWOvJ2rTqrus0N91vEs4JK+2eJ5LGO185Wiun9o9b5q+Kg+ypQo+XwhVX I+N8SO0cRtv/NtFNVmTiiHxWfUTQoJca1MZXs3Icn/OSwBrdCuh8b/XHxIEV2koqWqLz Axgw== X-Received: by 10.194.11.70 with SMTP id o6mr18946652wjb.29.1364340521461; Tue, 26 Mar 2013 16:28:41 -0700 (PDT) Received: from [192.168.1.2] ([85.48.237.92]) by mx.google.com with ESMTPS id ed6sm6392389wib.9.2013.03.26.16.28.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Mar 2013 16:28:40 -0700 (PDT) Message-ID: <51522F29.1020605@gmail.com> Date: Wed, 27 Mar 2013 00:28:41 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <5151D9E5.4090806@alum.mit.edu> <5151E9A1.90002@alum.mit.edu> <515223A5.7050209@gmail.com> <92B7E61ADAC1BB4F941F943788C08828047DD582@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047DD582@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 23:28:43 -0000 El 27/03/2013 0:12, Charles Eckel (eckelcu) escribió: >> El 26/03/2013 19:32, Paul Kyzivat escribió: >>> You seem to be assuming a couple of things that I am not: >>> >>> - that we only care about bfcp with conferences, not p2p calls. >> While BFCP can be used in p2p calls, I don't think it is its main use >> case, from the RFC: >> >> Scope >> >> As stated earlier, BFCP is a protocol to coordinate access to shared >> resources in a conference following the requirements defined in [9]. >> Floor control complements other functions defined in the XCON >> conferencing framework [10]. >> >> >> Also, coordinating the access to a shared resource between two parties >> in which one of them has the ownership of the resource doesn't seem >> quite a big deal. > I agree that coordination between two parties is easier than among many parties. That said, with SIP based video conferencing implementations, the same coordination is used for both cases. The determination of which side owns which resource is via SDP, and the real-time request and granting of the resource is via BFCP. For sessions between an endpoint and a conference focus, the conference focus typically requires that it be the owner of the content sharing resource. For point to point calls, it could be either endpoint assuming this role. This way the same SDP negotiation and BFCP messaging is used consistently for both conference and point to point calls. > I agree that having the same sollution for p2p and conference would be a nice to have. But, in my opinion implementing the logic on top of BFCP is the hard part for the client side. Given than the JS interface for websockets and datachannel is very similar (only setup is different), it will be fairly trivial for clients to support BOTH transport protocols and select which one to use depending on the SDP negotiation. Best regards Sergio From richard.ejzak@alcatel-lucent.com Wed Mar 27 12:38:48 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49DD21F9205 for ; Wed, 27 Mar 2013 12:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 52EBdU9a7KQ4 for ; Wed, 27 Mar 2013 12:38:47 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 43D7821F91FB for ; Wed, 27 Mar 2013 12:38:43 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r2RJcc5Y020537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 27 Mar 2013 14:38:38 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r2RJccK5020482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 27 Mar 2013 15:38:38 -0400 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.224]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 27 Mar 2013 15:38:38 -0400 From: "Ejzak, Richard P (Richard)" To: "dispatch@ietf.org" Thread-Topic: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt Thread-Index: AQHOKnmrQl2+PnTVHUuhtT6b7gjNJpi5tezg Date: Wed, 27 Mar 2013 19:38:37 +0000 Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EBC8A3@US70TWXCHMBA12.zam.alcatel-lucent.com> References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <5151D9E5.4090806@alum.mit.edu> <5151E9A1.90002@alum.mit.edu> <515223A5.7050209@gmail.com> <92B7E61ADAC1BB4F941F943788C08828047DD582@xmb-aln-x08.cisco.com> <51522F29.1020605@gmail.com> In-Reply-To: <51522F29.1020605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 19:38:49 -0000 PiBGcm9tOiBTZXJnaW8gR2FyY2lhIE11cmlsbG8NCj4gU2VudDogVHVlc2RheSwgTWFyY2ggMjYs IDIwMTMgNjoyOSBQTQ0KDQo+IEkgYWdyZWUgdGhhdCBoYXZpbmcgdGhlIHNhbWUgc29sbHV0aW9u IGZvciBwMnAgYW5kIGNvbmZlcmVuY2Ugd291bGQgYmUNCj4gYSBuaWNlIHRvIGhhdmUuIEJ1dCwg aW4gbXkgb3BpbmlvbiBpbXBsZW1lbnRpbmcgdGhlIGxvZ2ljIG9uIHRvcCBvZg0KPiBCRkNQIGlz IHRoZSBoYXJkIHBhcnQgZm9yIHRoZSBjbGllbnQgc2lkZS4gR2l2ZW4gdGhhbiB0aGUgSlMgaW50 ZXJmYWNlDQo+IGZvciB3ZWJzb2NrZXRzIGFuZCBkYXRhY2hhbm5lbCBpcyB2ZXJ5IHNpbWlsYXIg KG9ubHkgc2V0dXAgaXMNCj4gZGlmZmVyZW50KSwgaXQgd2lsbCBiZSBmYWlybHkgdHJpdmlhbCBm b3IgY2xpZW50cyB0byBzdXBwb3J0IEJPVEgNCj4gdHJhbnNwb3J0IHByb3RvY29scyBhbmQgc2Vs ZWN0IHdoaWNoIG9uZSB0byB1c2UgZGVwZW5kaW5nIG9uIHRoZSBTRFANCj4gbmVnb3RpYXRpb24u DQoNCldlIG1pZ2h0IHdhbnQgdG8gY29uc2lkZXIgdGhpcyBpbiBhIHdpZGVyIGNvbnRleHQsIGFz IHRoZXJlIGFyZSBvdGhlciBwcm90b2NvbHMgd2Ugc2hvdWxkIGNvbnNpZGVyIGZvciBXUyAod2Vi c29ja2V0cykgb3IgREMgKGRhdGEgY2hhbm5lbCkgdHJhbnNwb3J0LCBlLmcuLCBUMTQwIGFuZCBN U1JQLiAgUDJQIGlzIG1vcmUgY29tbW9uIHdpdGggdGhlc2UgcHJvdG9jb2xzLCB3aGVyZSBEQyBt YWtlcyBtb3JlIHNlbnNlLiAgV2hpbGUgV1MgY2FuIGJlIHVzZWQgZm9yIGUybSBhbmQgbGVnYWN5 IHNjZW5hcmlvcywgaXQgc2VlbXMgcHJlZmVyYWJsZSBldmVuIGhlcmUgdG8gdXNlIERDIHRvIGVu YWJsZSBtdXhpbmcgd2l0aCBvdGhlciBtZWRpYS4gIEV2ZW4gdGhvdWdoIGEgY2xpZW50IGNvdWxk IHN1cHBvcnQgYm90aCwgREMgY2FuIGJlIG1vcmUgZWZmaWNpZW50IGluIG1vc3QgY2FzZXMuICAN Cg0KDQo+IEZyb206IFJpY2hhcmQgQmFybmVzDQo+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI2LCAy MDEzIDEyOjI2IFBNDQoNCj4gSXQgbWF5IGJlIHRoYXQgaW1wbGVtZW50aW5nIFdTIG9uIHRoZSBz ZXJ2ZXIgc2lkZSBpcyBlYXNpZXIgdGhhbg0KPiBEYXRhQ2hhbm5lbC4gIEhvd2V2ZXIsIHRoYXQn cyBvbmx5IGJlY2F1c2UgdGhlcmUgYXJlIG5vIGxpYnJhcmllcw0KPiBhdmFpbGFibGUgcmlnaHQg bm93LiAgV1MgaXMgbm90IGEgZHJlYW0gdG8gaW1wbGVtZW50IGVpdGhlciwgYnV0IHRoZXJlDQo+ IHdhcyBlbm91Z2ggaW50ZXJlc3QgYW5kIHBlb3BsZSBidWlsdCB0aGUgbGlicmFyaWVzLiAgVGhl cmUncyBlbm91Z2gNCj4gaW50ZXJlc3QgaW4gRGF0YUNoYW5uZWwgdGhhdCBJIHdvdWxkbid0IGJl IHN1cnByaXNlZCBpZiB0aGUgc2FtZSB0aGluZw0KPiBoYXBwZW5zLg0KLi4uDQogDQo+IE9uIHRo ZSBvdGhlciBoYW5kOiBUaGVyZSdzIG5vdCByZWFsbHkgYSBnb29kIHN5bnRheCBmb3Igc2F5aW5n ICJ0aGlzDQo+IERhdGFDaGFubmVsIHN0cmVhbSB3aWxsIGJlIHVzZWQgZm9yIEJGQ1AiLiAgU28g YWRkaW5nIFdTIGFzIGEgdHJhbnNwb3J0DQo+IGZvciBCRkNQLCBvbiBpdHMgb3duIE0tbGluZSwg c2VlbXMgbGlrZSBhIHNpbXBsZXIgd2F5IHRvIGFsbG93IGZvcg0KPiBsZWdhY3kgaW50ZXJvcGVy YWJpbGl0eS4gIExlZ2FjeSBpbXBsZW1lbnRhdGlvbnMgd291bGQgb25seSBoYXZlIHRvIGFkZA0K PiB0aGUgV1MgdHJhbnNwb3J0IGZvciBCRkNQLCBhcyBvcHBvc2VkIHRvIGFkZGluZyBhbm90aGVy IGxheWVyIG9mDQo+IHByb2Nlc3Npbmcgb24gdG9wIG9mIFNEUCAoaS5lLiwgaWRlbnRpZnlpbmcg RGF0YUNoYW5uZWwgc3RyZWFtcykuDQoNCkknbSBub3Qgc3VyZSB0aGF0IHRoZXJlIGlzIGEgc2ln bmlmaWNhbnQgZGlmZmVyZW5jZSBpbiBjb21wbGV4aXR5IGJldHdlZW4gYWRkaW5nIGEgQkZDUCBv dmVyIFdTIG0tbGluZSB0byBTRFAgY29tcGFyZWQgdG8gaW5zZXJ0aW5nIGEgQkZDUCBvdmVyIERD IHN0cmVhbSBhdHRyaWJ1dGUgd2l0aGluIHRoZSBEQyBtLWxpbmUuICBUaGUgb25seSBkaWZmZXJl bmNlIEkgY2FuIGZhdGhvbSBpcyB0aGF0IHRoZSBsYXR0ZXIgcmVxdWlyZXMgZmluZGluZyB0aGUg REMgbS1saW5lIHdpdGhpbiB0aGUgU0RQIHRvIGluc2VydCB0aGUgYWRkaXRpb25hbCBhdHRyaWJ1 dGUgd2hpbGUgdGhlIGZvcm1lciBjYW4ganVzdCBiZSBhcHBlbmRlZC4NCg0KVGhlcmUgYWxzbyBz ZWVtcyB0byBiZSBhbiBhc3N1bXB0aW9uIGhlcmUgdGhhdCBwMnAgc2NlbmFyaW9zIGNvdWxkIG5v dCBiZW5lZml0IGZyb20gaGF2aW5nIHRoZSBvcHRpb24gdG8gdXNlIFNEUCB0byBuZWdvdGlhdGUg dGhlIHVzZSBvZiBCRkNQIChvciBvdGhlciBwcm90b2NvbHMpIG9uIGEgREMuICBJbiBwMnAgY2Fz ZXMgd2hlcmUgdGhlIHBlZXJzIGV4ZWN1dGUgZGlmZmVyZW50IHdlYnJ0YyBhcHBsaWNhdGlvbnMs IGl0IHdvdWxkIGJlIGFuIGFkdmFudGFnZSB0byBkaXNjb3ZlciB1cCBmcm9udCBkdXJpbmcgdGhl IG9mZmVyL2Fuc3dlciBleGNoYW5nZSB3aGljaCBEQyBwcm90b2NvbHMgY2FuIGJlIHN1cHBvcnRl ZCBiZWZvcmUgZG9pbmcgYWxsIHRoZSB3b3JrIHRvIHNldCB1cCBJQ0UsIERUTFMgYW5kIHRoZSBT Q1RQIGFzc29jaWF0aW9uLiAgV2hpbGUgbWFueSBwMnAgY29ubmVjdGlvbnMgd2lsbCBiZSBiYXNl ZCBvbiBydW5uaW5nIHRoZSBzYW1lIGFwcGxpY2F0aW9uIGluIGJvdGggcGVlcnMsIGRvIHdlIG5l ZWQgdG8gbWFuZGF0ZSBvciBldmVuIGFzc3VtZSB0aGlzPw0KDQpJIHdvdWxkIHByZWZlciB0byBo YXZlIHRoZSBvcHRpb24gdG8gc2lnbmFsIHRoZSB1c2Ugb2YgQkZDUCAoYW5kIG90aGVyIHByb3Rv Y29scykgb3ZlciBEQyB3aXRoaW4gU0RQLiAgVGhlcmUgaXMgbm8gbmVlZCB0byBkZWZpbmUgdGhl IFNEUCBleHRlbnNpb24gbmVlZGVkIHRvIGRvIHRoaXMgdW50aWwgdGhlIGZpcnN0IHRpbWUgd2Ug ZGVmaW5lIGhvdyB0byB0cmFuc3BvcnQgQkZDUCAob3Igc29tZSBvdGhlciBwcm90b2NvbCkgb3Zl ciBEQy4NCg0K From shida@ntt-at.com Wed Mar 27 22:55:33 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7489021F8F01 for ; Wed, 27 Mar 2013 22:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 Rh1Z6kcaeOzS for ; Wed, 27 Mar 2013 22:55:32 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id CDE4221F8EC2 for ; Wed, 27 Mar 2013 22:55:32 -0700 (PDT) Received: from [50.152.169.249] (port=59968 helo=[192.168.1.23]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1UL5oA-00088a-Rl; Thu, 28 Mar 2013 00:55:31 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Shida Schubert In-Reply-To: <00d901ce25c4$83a61340$8af239c0$@nttdocomo.co.jp> Date: Wed, 27 Mar 2013 22:55:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <687AE852-41E7-462D-B390-7DDBD43991B6@ntt-at.com> References: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> <7D2F7D7ADBA812449F25F4A69922881C081C7E@ESESSMB203.ericsson.se> <001c01ce218e$444ad2b0$cce07810$@gmx.com> <059F3547244B7F4DB728757635C2DC4B032DA1@DEMUMBX003.nsn-intra.net> <1362EB141A7E674397C8F8EB62AB1FA96A78217B@ex1.seri.co.uk> <00d901ce25c4$83a61340$8af239c0$@nttdocomo.co.jp> To: Itsuma TANAKA X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.23]) [50.152.169.249]:59968 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 05:55:33 -0000 +1 for them going forward..=20 Regards Shida=20 On Mar 20, 2013, at 4:41 PM, Itsuma TANAKA wrote: > Dear All, >=20 > I fully support these drafts going forward. >=20 > Regards, > Itsuma Tanaka >=20 > -------------------------------------------------------- > Itsuma TANAKA (=E7=94=B0=E4=B8=AD=E5=A8=81=E6=B4=A5=E9=A6=AC) > GSMA IREG Vice Chair / IREG Packet Chair > NTT DOCOMO, Inc. > -------------------------------------------------------- >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Ricky Kaura > Sent: Wednesday, March 20, 2013 11:16 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn = and, draft-allen-dispatch-imei-urn-as-instanceid submitted >=20 > Hello, >=20 > I also support these drafts going forward. >=20 > Regards, >=20 > Ricky Kaura. >=20 > Principal Standards Engineer > Standands and Industry Affairs (SIA) > Samsung Research and development institute United Kingdom (SRUK) > Tel: +44 (0) 1784 428 600 Ext 635; Mob: +44 (0) 7760 761514; Fax: = +44 (0) 1784 428 610 > Email: ricky.kaura@samsung.com; Skype: rickykaura; Yahoo: rkaura1969 = Samsung Electronics (UK) Limited Registered number: 03086621 Registered = address: Communications house, South Street, Staines, Middlesex TW18 = 4QE. >=20 > -----Original Message----- > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com] > Sent: 20 March 2013 07:16 > To: dispatch@ietf.org > Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn = and, draft-allen-dispatch-imei-urn-as-instanceid submitted >=20 > +1 >=20 > Regards, > Peter >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext Georg Mayer > Sent: Friday, March 15, 2013 4:04 PM > To: 'Atle Monrad'; 'Dale R. Worley'; dispatch@ietf.org > Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn = and, draft-allen-dispatch-imei-urn-as-instanceid submitted >=20 > Hello, >=20 > I fully support these drafts going forward now. It would be great = seeing them completed within short time. After Andrews clarifications I = do not see any reason to hold them back any longer. >=20 > Thanks, > Georg=20 >=20 >=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Atle Monrad > Gesendet: Dienstag, 12. M=C3=A4rz 2013 23:35 > An: Dale R. Worley; dispatch@ietf.org > Betreff: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn = and, draft-allen-dispatch-imei-urn-as-instanceid submitted >=20 > Dale / all >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From R.Jesske@telekom.de Wed Mar 27 22:58:30 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1401421F929F for ; Wed, 27 Mar 2013 22:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 l3MHGpGPPVoW for ; Wed, 27 Mar 2013 22:58:29 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0894921F9296 for ; Wed, 27 Mar 2013 22:58:28 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 28 Mar 2013 06:58:27 +0100 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 28 Mar 2013 06:58:26 +0100 From: To: , Date: Thu, 28 Mar 2013 06:58:26 +0100 Thread-Topic: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted Thread-Index: Ac4reOJfXWacoV6nS1i+UrOkFZ7r+QAAD6nw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D16E472A0B7@HE111648.emea1.cds.t-internal.com> References: <201303121816.r2CIGXJg289532@shell01.TheWorld.com> <7D2F7D7ADBA812449F25F4A69922881C081C7E@ESESSMB203.ericsson.se> <001c01ce218e$444ad2b0$cce07810$@gmx.com> <059F3547244B7F4DB728757635C2DC4B032DA1@DEMUMBX003.nsn-intra.net> <1362EB141A7E674397C8F8EB62AB1FA96A78217B@ex1.seri.co.uk> <00d901ce25c4$83a61340$8af239c0$@nttdocomo.co.jp> <687AE852-41E7-462D-B390-7DDBD43991B6@ntt-at.com> In-Reply-To: <687AE852-41E7-462D-B390-7DDBD43991B6@ntt-at.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: dispatch@ietf.org Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 05:58:30 -0000 SSdtIGFsc28gaW4gc3VwcG9ydCB0byBwcm9jZWVkIHdpdGggdGhpcyBkcmFmdHMuDQoNClJvbGFu ZA0KDQo+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiBkaXNwYXRj aC1ib3VuY2VzQGlldGYub3JnDQo+IFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10g SW0gQXVmdHJhZyB2b24gU2hpZGEgU2NodWJlcnQNCj4gR2VzZW5kZXQ6IERvbm5lcnN0YWcsIDI4 LiBNw6RyeiAyMDEzIDA2OjU1DQo+IEFuOiBJdHN1bWEgVEFOQUtBDQo+IENjOiBkaXNwYXRjaEBp ZXRmLm9yZw0KPiBCZXRyZWZmOiBSZTogW2Rpc3BhdGNoXSBOZXcgVmVyc2lvbnMgb2YNCj4gZHJh ZnQtbW9udGVtdXJyby1nc21hLWltZWktdXJuIGFuZCwNCj4gZHJhZnQtYWxsZW4tZGlzcGF0Y2gt aW1laS11cm4tYXMtaW5zdGFuY2VpZCBzdWJtaXR0ZWQNCj4NCj4NCj4gKzEgZm9yIHRoZW0gZ29p bmcgZm9yd2FyZC4uDQo+DQo+IFJlZ2FyZHMNCj4gIFNoaWRhDQo+DQo+IE9uIE1hciAyMCwgMjAx MywgYXQgNDo0MSBQTSwgSXRzdW1hIFRBTkFLQSB3cm90ZToNCj4NCj4gPiBEZWFyIEFsbCwNCj4g Pg0KPiA+IEkgZnVsbHkgc3VwcG9ydCB0aGVzZSBkcmFmdHMgZ29pbmcgZm9yd2FyZC4NCj4gPg0K PiA+IFJlZ2FyZHMsDQo+ID4gSXRzdW1hIFRhbmFrYQ0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBJdHN1bWEgVEFO QUtBICjnlLDkuK3lqIHmtKXppqwpDQo+ID4gR1NNQSBJUkVHIFZpY2UgQ2hhaXIgLyBJUkVHIFBh Y2tldCBDaGFpciBOVFQgRE9DT01PLCBJbmMuDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+DQo+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnDQo+ IFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPiBCZWhhbGYgT2YgUmlj a3kgS2F1cmENCj4gPiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDIwLCAyMDEzIDExOjE2IFBNDQo+ ID4gVG86IGRpc3BhdGNoQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gTmV3 IFZlcnNpb25zIG9mDQo+IGRyYWZ0LW1vbnRlbXVycm8tZ3NtYS1pbWVpLXVybg0KPiA+IGFuZCwg ZHJhZnQtYWxsZW4tZGlzcGF0Y2gtaW1laS11cm4tYXMtaW5zdGFuY2VpZCBzdWJtaXR0ZWQNCj4g Pg0KPiA+IEhlbGxvLA0KPiA+DQo+ID4gSSBhbHNvIHN1cHBvcnQgdGhlc2UgZHJhZnRzIGdvaW5n IGZvcndhcmQuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+DQo+ID4gUmlja3kgS2F1cmEuDQo+ID4N Cj4gPiBQcmluY2lwYWwgU3RhbmRhcmRzIEVuZ2luZWVyDQo+ID4gU3RhbmRhbmRzIGFuZCBJbmR1 c3RyeSBBZmZhaXJzIChTSUEpDQo+ID4gU2Ftc3VuZyBSZXNlYXJjaCBhbmQgZGV2ZWxvcG1lbnQg aW5zdGl0dXRlIFVuaXRlZCBLaW5nZG9tIChTUlVLKQ0KPiA+IFRlbDogICArNDQgKDApIDE3ODQg NDI4IDYwMCBFeHQgNjM1OyBNb2I6ICs0NCAoMCkgNzc2MA0KPiA3NjE1MTQ7IEZheDogKzQ0ICgw KSAxNzg0IDQyOCA2MTANCj4gPiBFbWFpbDogcmlja3kua2F1cmFAc2Ftc3VuZy5jb207IFNreXBl OiByaWNreWthdXJhOyBZYWhvbzoNCj4gcmthdXJhMTk2OSBTYW1zdW5nIEVsZWN0cm9uaWNzIChV SykgTGltaXRlZCBSZWdpc3RlcmVkDQo+IG51bWJlcjogMDMwODY2MjEgUmVnaXN0ZXJlZCBhZGRy ZXNzOiBDb21tdW5pY2F0aW9ucyBob3VzZSwNCj4gU291dGggU3RyZWV0LCBTdGFpbmVzLCBNaWRk bGVzZXggVFcxOCA0UUUuDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ IEZyb206IExlaXMsIFBldGVyIChOU04gLSBERS9NdW5pY2gpIFttYWlsdG86cGV0ZXIubGVpc0Bu c24uY29tXQ0KPiA+IFNlbnQ6IDIwIE1hcmNoIDIwMTMgMDc6MTYNCj4gPiBUbzogZGlzcGF0Y2hA aWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBOZXcgVmVyc2lvbnMgb2YNCj4g ZHJhZnQtbW9udGVtdXJyby1nc21hLWltZWktdXJuDQo+ID4gYW5kLCBkcmFmdC1hbGxlbi1kaXNw YXRjaC1pbWVpLXVybi1hcy1pbnN0YW5jZWlkIHN1Ym1pdHRlZA0KPiA+DQo+ID4gKzENCj4gPg0K PiA+IFJlZ2FyZHMsDQo+ID4gUGV0ZXINCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gRnJvbTogZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZw0KPiBbbWFpbHRvOmRpc3Bh dGNoLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gQmVoYWxmIE9mIGV4dCBHZW9yZyBNYXllcg0K PiA+IFNlbnQ6IEZyaWRheSwgTWFyY2ggMTUsIDIwMTMgNDowNCBQTQ0KPiA+IFRvOiAnQXRsZSBN b25yYWQnOyAnRGFsZSBSLiBXb3JsZXknOyBkaXNwYXRjaEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6 IFJlOiBbZGlzcGF0Y2hdIE5ldyBWZXJzaW9ucyBvZg0KPiBkcmFmdC1tb250ZW11cnJvLWdzbWEt aW1laS11cm4NCj4gPiBhbmQsIGRyYWZ0LWFsbGVuLWRpc3BhdGNoLWltZWktdXJuLWFzLWluc3Rh bmNlaWQgc3VibWl0dGVkDQo+ID4NCj4gPiBIZWxsbywNCj4gPg0KPiA+IEkgZnVsbHkgc3VwcG9y dCB0aGVzZSBkcmFmdHMgZ29pbmcgZm9yd2FyZCBub3cuIEl0IHdvdWxkIGJlDQo+IGdyZWF0IHNl ZWluZyB0aGVtIGNvbXBsZXRlZCB3aXRoaW4gc2hvcnQgdGltZS4gQWZ0ZXIgQW5kcmV3cw0KPiBj bGFyaWZpY2F0aW9ucyBJIGRvIG5vdCBzZWUgYW55IHJlYXNvbiB0byBob2xkIHRoZW0gYmFjayBh bnkgbG9uZ2VyLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IEdlb3JnDQo+ID4NCj4gPg0KPiA+DQo+ ID4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiA+IFZvbjogZGlzcGF0Y2gt Ym91bmNlc0BpZXRmLm9yZw0KPiBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIElt DQo+ID4gQXVmdHJhZyB2b24gQXRsZSBNb25yYWQNCj4gPiBHZXNlbmRldDogRGllbnN0YWcsIDEy LiBNw6RyeiAyMDEzIDIzOjM1DQo+ID4gQW46IERhbGUgUi4gV29ybGV5OyBkaXNwYXRjaEBpZXRm Lm9yZw0KPiA+IEJldHJlZmY6IFJlOiBbZGlzcGF0Y2hdIE5ldyBWZXJzaW9ucyBvZg0KPiBkcmFm dC1tb250ZW11cnJvLWdzbWEtaW1laS11cm4NCj4gPiBhbmQsIGRyYWZ0LWFsbGVuLWRpc3BhdGNo LWltZWktdXJuLWFzLWluc3RhbmNlaWQgc3VibWl0dGVkDQo+ID4NCj4gPiBEYWxlIC8gYWxsDQo+ ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPiA+IGRpc3BhdGNoQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KPiA+DQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGRp c3BhdGNoIG1haWxpbmcgbGlzdA0KPiA+IGRpc3BhdGNoQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkaXNwYXRjaCBtYWlsaW5nIGxp c3QNCj4gZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kaXNwYXRjaA0KPg0K From keith.drage@alcatel-lucent.com Thu Mar 28 05:35:55 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD29921F8E5E for ; Thu, 28 Mar 2013 05:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 0GvdML15Gto9 for ; Thu, 28 Mar 2013 05:35:55 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4C41921F8CCD for ; Thu, 28 Mar 2013 05:35:55 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r2SCZrVf021041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 28 Mar 2013 07:35:54 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r2SCZmNV020031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 28 Mar 2013 08:35:53 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 28 Mar 2013 08:35:53 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 28 Mar 2013 13:35:43 +0100 From: "DRAGE, Keith (Keith)" To: "dispatch@ietf.org" Thread-Topic: Use of BFCP or MSRP over datachannel or websocket Thread-Index: Ac4rsMGiPKz1pFC/QlekwsQdT+Np8Q== Date: Thu, 28 Mar 2013 12:35:43 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 12:35:55 -0000 >From what I have seen of the discussion so far, there appears to be a body = of support that there is a use case for both BFCP and MSRP over websocket, = for use in a non-rtcweb environment. If when we get to the rtcweb environment we allow this, and also allow a us= age over datachannel version, we essentially have two solutions in the mark= et place. If that occurs, what guidance will we give to a rtcweb developer as to whic= h to implement? Or do we envisage that only one will be allowed (and if so which) in an rtc= web environment? Regards Keith From mary.ietf.barnes@gmail.com Thu Mar 28 07:58:28 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7100721F8B8F for ; Thu, 28 Mar 2013 07:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 RcL7u0XcAB0O for ; Thu, 28 Mar 2013 07:58:26 -0700 (PDT) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 43B6E21F8B65 for ; Thu, 28 Mar 2013 07:58:25 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id i11so5275685qej.13 for ; Thu, 28 Mar 2013 07:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=578qnMoy5uK9eLJiIRE8SVwKCB3eDLTc6KKWYbgXhTY=; b=bN03bn/wE2Ggvxj6Lsjo70Y+d03E+0hmJWmOXWT1VlrQrvKYo07t2Dv8nxchgvUZPR vVKTy6MMfY892Hr2oIyycjTRQ65qgejaWs4t7snxufGM1S/M1qQzDmjaJvHWhL3nkyyf 07pa/UF+socvv6+AHQqCNmDEpYHMbvTrO36q2TSx3fUkCpL255c0DqMzE8EVTrRGMLu4 Q9R1A+1Ud2s2Q40qjmHPoYcMIJegKtAFLR5laemZT0BeBaXwutkUpNR5CBM81wb5q/gQ 7LdBDAnnTs4H/tJ5tg7444ytop0I5PSkWEOHYyD9WtNL8xI6Qs7JGfsoCFfEY4F7T9IV htWA== MIME-Version: 1.0 X-Received: by 10.229.137.75 with SMTP id v11mr3457783qct.26.1364482704771; Thu, 28 Mar 2013 07:58:24 -0700 (PDT) Received: by 10.49.94.166 with HTTP; Thu, 28 Mar 2013 07:58:24 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 28 Mar 2013 09:58:24 -0500 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 14:58:28 -0000 I don't think it's the job of dispatch or BFCPbis WG to define or even make recommendations for RTCWEB. That choice is up to the RTCWEB WG and it shouldn't be influencing this work. There are applications other than RTCWEB that can and will make use of BFCPbis over websockets. I really don't understand why we are getting so hung up on this - it's the BFCP messages themselves that are important - how one chooses to transport is up to the application. Mary. On Thu, Mar 28, 2013 at 7:35 AM, DRAGE, Keith (Keith) wrote: > From what I have seen of the discussion so far, there appears to be a body of support that there is a use case for both BFCP and MSRP over websocket, for use in a non-rtcweb environment. > > If when we get to the rtcweb environment we allow this, and also allow a usage over datachannel version, we essentially have two solutions in the market place. > > If that occurs, what guidance will we give to a rtcweb developer as to which to implement? > > Or do we envisage that only one will be allowed (and if so which) in an rtcweb environment? > > > > Regards > > Keith > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Thu Mar 28 09:10:48 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD6821F8AC3 for ; Thu, 28 Mar 2013 09:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.342 X-Spam-Level: X-Spam-Status: No, score=-0.342 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 w51iwmOvJdDg for ; Thu, 28 Mar 2013 09:10:47 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 08C5921F8A91 for ; Thu, 28 Mar 2013 09:10:46 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id GxW51l00H0cZkys534Amz6; Thu, 28 Mar 2013 16:10:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id H4Am1l00P3ZTu2S3W4Am45; Thu, 28 Mar 2013 16:10:46 +0000 Message-ID: <51546B85.8020804@alum.mit.edu> Date: Fri, 29 Mar 2013 00:10:45 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364487046; bh=G9EYBagI6Lrz9Y3TlSieJcCdVvvVwZrkdb5gV1C/wZ0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fjIXXuhI7zYbg57BVNtd6XzpESZF6oWxgiwPHM3Lw02Nak0BWIs3ny7SPFDJVj/A/ EW6RKGAi0zP9L9XoC4ro3fz5FVeHfvMsSbEmO62ZGtDHxQ9jqhC4Q1uzgh+Pwf8oXv qGxV1ZLwSHbiWB0jth/hbI+rDeh0YKoyvNp9ca4GfS0bpvCj4mJt+01PIXbL1Axrgv mY2ux/Ip/DLKOFiBwhOGQUbXpn9PSLXVgPZxGbru61VEpFCLDeUpO9yKamgdf/Wnlg IIUBxNXiCsgpFBIrGTI1zwMQo9QhM5UfmE4UmNNCKbA0qhO5wNtpNwNCn8qyiTScJC X7XEiMjEQgMlQ== Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 16:10:48 -0000 On 3/28/13 8:35 PM, DRAGE, Keith (Keith) wrote: >>From what I have seen of the discussion so far, there appears to be a body of support that there is a use case for both BFCP and MSRP over websocket, for use in a non-rtcweb environment. > > If when we get to the rtcweb environment we allow this, and also allow a usage over datachannel version, we essentially have two solutions in the market place. Two choices for the rtcweb developer and *four* for the sip developer!!! And sip developers might find themselves gatewayed to rtcweb applications. > If that occurs, what guidance will we give to a rtcweb developer as to which to implement? > > Or do we envisage that only one will be allowed (and if so which) in an rtcweb environment? That is the dilemma! Less is better. Thanks, Paul From sergio.garcia.murillo@gmail.com Thu Mar 28 09:50:30 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1872921F8A84 for ; Thu, 28 Mar 2013 09:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=1.728, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 U3ivhtd59etM for ; Thu, 28 Mar 2013 09:50:29 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 37BB021F8749 for ; Thu, 28 Mar 2013 09:50:25 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id l18so1677258wgh.13 for ; Thu, 28 Mar 2013 09:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bBpSXF+OyXDmcIcAjH5Bbrsfu6Pu4xR0Qqmq/AwhKwc=; b=F+f2yf4QTxjXz/Jzx88vFCVqXtTcv71ozd0CHceEYbb6AaRDacNh1KwjnmZYnV7PzS hlfrHimDsxzSr2BXiIPGAyBCIcvk7yTCxHS7ESSjJJXuc7VmFlByoIbCAlbWabiclb9Y kFBeZNOH9H4K9V1UaBn9CBMWnmkaOUGt8EdESw617zuqhBzVA7pYPwxvE2n2Pgtnm0Nq BTJJnS1ftUQUY9L6ocvpYNsfHcMfP0sSF05K1GfpVRT0jPRVgTwdjm88DfHnVOAHugvz 1bR7lCC4Kx+cebNJBtNI2FUwKvFpHT2knYbGHH9Z191fAAXRlSHHlpDRkbts8TRNB/J7 ontg== X-Received: by 10.194.89.169 with SMTP id bp9mr39812138wjb.57.1364489424450; Thu, 28 Mar 2013 09:50:24 -0700 (PDT) Received: from [192.168.1.2] ([85.48.237.92]) by mx.google.com with ESMTPS id ed6sm16929262wib.9.2013.03.28.09.50.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 09:50:23 -0700 (PDT) Message-ID: <515474D3.1010108@gmail.com> Date: Thu, 28 Mar 2013 17:50:27 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 16:50:30 -0000 El 28/03/2013 13:35, DRAGE, Keith (Keith) escribió: > From what I have seen of the discussion so far, there appears to be a body of support that there is a use case for both BFCP and MSRP over websocket, for use in a non-rtcweb environment. > > If when we get to the rtcweb environment we allow this, and also allow a usage over datachannel version, we essentially have two solutions in the market place. > > If that occurs, what guidance will we give to a rtcweb developer as to which to implement? > > Or do we envisage that only one will be allowed (and if so which) in an rtcweb environment? What do you consider to be a "rtcweb developer"? The developers of the webrtc browsers? They do not need to implement anything. The developers of server side webrtc products (i.e. conference servers)? Been one of them, I can tell you that websockets is my preferred option. The developers of a service using webrtc? They will either use (not implement) datachannels if no server component is involved or whatever their server provides otherwise. As someone else in the list pointed out, the main thing is to be define the JSON serialization of the BCFP messages and let anyone choose their preferred transport. Even BFCP over MSRP over websockets could be used.. :P Best regards Sergio From stpeter@stpeter.im Fri Mar 29 20:22:44 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE3E21E804E for ; Fri, 29 Mar 2013 20:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 rILtfnq8YiHJ for ; Fri, 29 Mar 2013 20:22:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 322AB21E804D for ; Fri, 29 Mar 2013 20:22:40 -0700 (PDT) Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 34F2840D4A; Fri, 29 Mar 2013 21:32:09 -0600 (MDT) Message-ID: <51565A7E.2050607@stpeter.im> Date: Fri, 29 Mar 2013 21:22:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, emcho@jitsi.org Subject: Re: [dispatch] Review of draft-ivov-xmpp-cusax-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 03:22:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/27/13 2:15 PM, Markus.Isomaki@nokia.com wrote: > Hi, > > I did a review of draft-ivov-xmpp-cusax-02. Markus, thanks for the review. Emil, Enrico and I have incorporated almost all of your feedback into the document and expect to submit version -04 soon. I have one comment below... > -- Client bootstrap > > The draft says: "While it should be possible for CUSAX users to > manually configure their separate SIP and XMPP accounts, > dual-stack SIP/XMPP clients ought to provide means of online > provisioning. While the specifics of such mechanisms are outside > the scope of this specification, they should make it possible for a > service provider to remotely configure the clients based on minimal > user input (e.g., only a user ID and password)." > > It is clearly said the mechanisms are out of scope. But in terms > of interoperability and deployment scenarios this is an important > question. Naturally any proprietary mechanisms can be used, but > that limits the deployment to cases where there is some kind of > special relationship between the SIP + XMPP client and at least > some part of the server infra. For independent clients, it would be > useful to at least point out and probably recommend some > mechanisms. In SIP there is the relatively recent UA configuration > work, and I believe XMPP has something directly targeted for > account/client provisioning. Those should be brought up. As far as I know, those efforts might be too immature to reference here. One example is the aggsrv BoF held at IETF 86 -- it might result in usable technologies, but much work will be required to produce that outcome. Perhaps the SIP UA configuration work is farther along, but we have nothing like that for XMPP. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRVlp9AAoJEOoGpJErxa2pNkIP/1mRt8Mhq6RsIBcXxwtCUR+x nBbq/LdHln3Zs762IYyxuj1FzWUXOZPxcRnTWpyJOfClnsU6jbTP+aQ0fxcrTuNa NpkyxvCnA4yjuL32xHKjy80uzlJVrUEV8XZ0QVRqiKNyLnttfz9F8Wa70u81jc6L 9Xhb+lWWuuggwr6IdqT4OKsyEF6TcBsLo1E+lvi6Q2U93s/3UzuZsKwnWEWtoX2k yGitGvvj6VD3VPUNAjZsOCAXiXpEvLRlotft+Wi5mmdiYSDfG+gLSIpX4p82lUbG FDPTa0SiSh5v55gRYsrYSr381E4eydFHCQqu+bwZ41k2EYOD5ctDUeGlpj3CpZys VvOY2e9Z8VbBVy4p256jW14gNzxjD4fCXmWzCcp7IJNC2ZWqQu7nPaYcXgSyQP2N cFOTvavsiL8BfhnLX46vmHr/LNk3fRXyNVVzXCUGlZoENKZg8Sz+NqjvRSbeMtso dwEQX1QKMWUJkk8w/MJby57OXFuLngosXn0gbUzjS6tSaAqwZWMnyY0qP1j9P221 NDv9UMUxVQfspwvgB/vx3kBqOQew0GSVQ7QZapUGBHmuzlmjgJX7zQPD51MFTgr3 PMMbBShreoX87edDPAsBJA4ADTeo0qVtyxeYUbY0uzDawc4pth7Ot/eEz3Z3H/ke sV3WSZN3PPOg7vpWhgC4 =pap7 -----END PGP SIGNATURE----- From partha@parthasarathi.co.in Sun Mar 31 09:36:56 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD3321F85CE for ; Sun, 31 Mar 2013 09:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.064 X-Spam-Level: *** X-Spam-Status: No, score=3.064 tagged_above=-999 required=5 tests=[AWL=5.029, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 EwwsfhV9jjyC for ; Sun, 31 Mar 2013 09:36:55 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6429921F85D4 for ; Sun, 31 Mar 2013 09:36:54 -0700 (PDT) Received: from userPC (unknown [122.179.55.107]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 824AC3E0CAE; Sun, 31 Mar 2013 16:36:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1364747814; bh=xgnVqkJzl0pU2ZeZ9I33j19bHjoZ8XtXV08VSwd9RWc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=a7rFLt4irugVGhygyyCDkCTNTYft/e/CTqqHluMDk9TURRKrAbAC3IUqQ/6+Pzz14 lioAelrsPrjcXD0M0msoOdIvnXXR6v5m1m7m3jmxpwRAqc6de9a0Q+Ha0f3txr4smW 5bxeCLSblrqdsUF7WeNDTrM8aN877wGw+KwoX8Nk= From: "Parthasarathi R" To: "'Avasarala, Ranjit \(NSN - IN/Bangalore\)'" , =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= , "'Paul Kyzivat'" References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <001e01ce2a3d$5cee5d20$16cb1760$@co.in> In-Reply-To: Date: Sun, 31 Mar 2013 22:06:46 +0530 Message-ID: <004201ce2e2d$f40705b0$dc151110$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOKj1omIsjwNEESUaBihJcMGDe2pi4M70wgAfQCsA= Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0207.51586626.007C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 16:36:56 -0000 Ranjit, As we discussed in offline, SIP focus and RTP mixer shall exists = physically different devices. It is possible to achieve using Sec 3.3. = of draft-ietf-bfcpbis-rfc4582bis mechanism or H.248. Thanks Partha=20 > -----Original Message----- > From: Avasarala, Ranjit (NSN - IN/Bangalore) > [mailto:ranjit.avasarala@nsn.com] > Sent: Tuesday, March 26, 2013 10:37 PM > To: ext Parthasarathi R; 'I=C3=B1aki Baz Castillo'; 'Paul Kyzivat' > Cc: dispatch@ietf.org > Subject: RE: [dispatch] FW: New Version Notification for = draft-pascual- > dispatch-bfcp-websocket-00.txt >=20 > Partha >=20 > I really do not think there can be a SIP focus which is just signaling > entity, it would also have RTP mixer. >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of ext Parthasarathi R > Sent: Tuesday, March 26, 2013 9:47 PM > To: 'I=C3=B1aki Baz Castillo'; 'Paul Kyzivat' > Cc: dispatch@ietf.org > Subject: Re: [dispatch] FW: New Version Notification for = draft-pascual- > dispatch-bfcp-websocket-00.txt >=20 > Hi all, >=20 > I agree with Paul that BFCP over data channel is preferred because > BFCP is not related to SIP (focus) but it is more relevant to media > layer. Irrespective of signaling layer is SIP or HTTP, BFCP shall be > carried in media layer specific protocols (data channel) rather than > signaling layer specific protocol (WebSocket). >=20 > In case of the architecture wherein conferenence signaling entity > (like SIP focus) is not physically co-located with RTP mixer, then > RTP Mixer has no need to implement WebSocket for sake of supporting > BFCP over WebSocket. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On > > Behalf Of I=C3=B1aki Baz Castillo > > Sent: Tuesday, March 26, 2013 2:37 PM > > To: Paul Kyzivat > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] FW: New Version Notification for draft- > pascual- > > dispatch-bfcp-websocket-00.txt > > > > 2013/3/26 Paul Kyzivat : > > > ISTM the main issue is that bfcp over datachannel can work peer to > > peer, > > > while bfcp over websocket will only be useful with a webserver in > the > > > middle. (Presumably that can be resolved in some cases by = inserting > a > > > websocket relay of some sort.) > > > > Hi Paul, which is the problem with having a relay server? This is = WWW > > and not SIP physical devices with fixed code. In WWW world, clients > > (browsers) connect to a central server (the WWW server, which now = can > > also be a WebSocket server) and signal with it. > > > > Honestly I don't like the idea of considering a JS application like = a > > standalone SIP client which does not run in the context of a = website, > > because that is not the way in which web apps work. So IMHO there is > > no advantage at all in having BFCP over data channel. In Web > > deployments the server wants to know about what happens in client > > side. I strongly discourage the vision of considering a JS > application > > something like a "desktop softphone". It's not. > > > > Also, BFCP is a "signaling protocol", so let's say "a light > protocol". > > It can be perfectly carried across central servers, there is no = need > > at all for using client-to-client communication (this is not a media > > flow but a signaling flow). > > > > > > In short, I consider having MSRP over DataChannel something useful, > > but I consider that any other SIP related protocol (that does not > > involve carrying big data) should be implemented over WebSocket and > > never over DataChannel. And even more: using DataChannel for > > "signaling" breaks the WWW rules because here we are not in SIP land > > but in WWW land in which central servers exist and want to be in the > > path of the communications between clients. > > > > > > Best regards. > > > > > > > > -- > > I=C3=B1aki Baz Castillo > > > > _______________________________________________ > > 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 partha@parthasarathi.co.in Sun Mar 31 09:52:34 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7C121F861B for ; Sun, 31 Mar 2013 09:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[AWL=2.664, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 GVLRtXmjIA+y for ; Sun, 31 Mar 2013 09:52:33 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id DC8EC21F84A1 for ; Sun, 31 Mar 2013 09:52:32 -0700 (PDT) Received: from userPC (unknown [122.179.55.107]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id BDC253E0B6B; Sun, 31 Mar 2013 16:52:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1364748752; bh=/RZesfbuDboHG4632tZ41lUtGVk2LNbBv8IRGP3DXC0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=e8BDTg22/EpKUUYcRKlntKmmy8RWXMMEznqP0dSagKRDsQSwzIpUjI4KF957eD7HP 4VNkXgMq+HzkzsXedDw5gYb9NZlMJuOozXUk83Sl9vsdYcdGsIvhLGKRMErWfGwIzW ThmN3PAwcUKSE8F97w7jYYYogNUa671Wd9aNS+Dk= From: "Parthasarathi R" To: "'Mary Barnes'" , "'DRAGE, Keith \(Keith\)'" References: <949EF20990823C4C85C18D59AA11AD8B01D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Date: Sun, 31 Mar 2013 22:22:27 +0530 Message-ID: <004301ce2e30$2317e700$6947b500$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4rxLfyJFzBAm7hRuald9lzAS7dEACadP4g Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0209.515869D0.0054, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: dispatch@ietf.org Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 16:52:34 -0000 The compelling reason for this draft is RTCWeb. In case of non-RTCWeb, TCP Shall be used which avoids the overhead introduced due to WebSocket. Please clarify in case WebSocket has some specific advantage over TCP in non-RTCWeb environment. In case dispatch or BFCPbis are not the right WG to make recommendation, then let us discuss in RTCWeb WG itself. Also, Please suggest if any other mailing list like (rai@ietf.org) is the right place to discuss. Thanks Partha > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: Thursday, March 28, 2013 8:28 PM > To: DRAGE, Keith (Keith) > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Use of BFCP or MSRP over datachannel or > websocket > > I don't think it's the job of dispatch or BFCPbis WG to define or even > make recommendations for RTCWEB. That choice is up to the RTCWEB WG > and it shouldn't be influencing this work. There are applications > other than RTCWEB that can and will make use of BFCPbis over > websockets. I really don't understand why we are getting so hung up > on this - it's the BFCP messages themselves that are important - how > one chooses to transport is up to the application. > > Mary. > > On Thu, Mar 28, 2013 at 7:35 AM, DRAGE, Keith (Keith) > wrote: > > From what I have seen of the discussion so far, there appears to be a > body of support that there is a use case for both BFCP and MSRP over > websocket, for use in a non-rtcweb environment. > > > > If when we get to the rtcweb environment we allow this, and also > allow a usage over datachannel version, we essentially have two > solutions in the market place. > > > > If that occurs, what guidance will we give to a rtcweb developer as > to which to implement? > > > > Or do we envisage that only one will be allowed (and if so which) in > an rtcweb environment? > > > > > > > > Regards > > > > Keith > > _______________________________________________ > > 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 partha@parthasarathi.co.in Sun Mar 31 09:56:37 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06ACD21F848A for ; Sun, 31 Mar 2013 09:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=1.626, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 xZB4Qm8dYiy6 for ; Sun, 31 Mar 2013 09:56:36 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0559721F8484 for ; Sun, 31 Mar 2013 09:56:35 -0700 (PDT) Received: from userPC (unknown [122.179.55.107]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 014663E0CAE; Sun, 31 Mar 2013 16:56:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1364748995; bh=3WKpP9dhnxANI7mWSNDQwOMjzNwsQ50u2uvempq7whA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=X8zzujSwq5vFNrJKU5HwyVgBdnBVj3aFxLuJOEUHe3QQY88Ccdxahei7cQMJnRhv9 pKPpv5ziyhR258USem/woDFzrAhcRj/r7UanWtTbyv7Umr61X/P28U2GCOgpC3nCS3 EE8rq+BgavXREhuGSXgdTc3bVGUKwRpVtnb4mTA8= From: "Parthasarathi R" To: =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <20130215171708.27730.58906.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D39A9@xmb-aln-x08.cisco.com> <51414032.3060902@alum.mit.edu> <5150DB96.5040201@alum.mit.edu> <001e01ce2a3d$5cee5d20$16cb1760$@co.in> In-Reply-To: Date: Sun, 31 Mar 2013 22:26:29 +0530 Message-ID: <004401ce2e30$b3780be0$1a6823a0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4qQGyuyVntvOL+SZSdjJC+Id7gbgD777Zg Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0205.51586AC3.00B4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 2 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: dispatch@ietf.org Subject: Re: [dispatch] FW: New Version Notification for draft-pascual-dispatch-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 16:56:37 -0000 I could not understand how 100 times tougher to implement in = datachannel. Please note that Conference RTP mixer products has to handle datachannel When they support RTCWeb. So, it is not so tough to implement. OTOH,=20 RTP Mixer may not have HTTP server itself wherein = implementing/maintaining Websocket application is real overhead. > -----Original Message----- > From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] > Sent: Tuesday, March 26, 2013 10:09 PM > To: Parthasarathi R > Cc: Paul Kyzivat; dispatch@ietf.org > Subject: Re: [dispatch] FW: New Version Notification for = draft-pascual- > dispatch-bfcp-websocket-00.txt >=20 > 2013/3/26 Parthasarathi R : > > In case of the architecture wherein conferenence signaling entity > > (like SIP focus) is not physically co-located with RTP mixer, then > > RTP Mixer has no need to implement WebSocket for sake of supporting > > BFCP over WebSocket. >=20 > No, it just has to implement DataChannel, which is 100 times more > difficult to implement than WebSocket. >=20 >=20 >=20 > -- > I=C3=B1aki Baz Castillo >