From dromasca@avaya.com Mon Jun 3 03:59:26 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112C021F93BA; Mon, 3 Jun 2013 03:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.664 X-Spam-Level: X-Spam-Status: No, score=-102.664 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 O+DoO+IVNpOH; Mon, 3 Jun 2013 03:59:18 -0700 (PDT) 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 F32C521F944F; Mon, 3 Jun 2013 03:59:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFAJV2rFGHCzI1/2dsb2JhbABTBoJoITC/BH8WdIIjAQEBAQMBAQEPKDQLEgEVCgsCEjcLHQoECgQDAggBGYdrAQueb5t8jW0IDHUxgn5hA51/in+DD0CBMTY X-IronPort-AV: E=Sophos;i="4.87,792,1363147200"; d="scan'208";a="14425008" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 Jun 2013 06:58:59 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Jun 2013 06:54:28 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.02.0328.009; Mon, 3 Jun 2013 06:58:58 -0400 From: "Romascanu, Dan (Dan)" To: The IESG Thread-Topic: WG Review: SIP-TO-XMPP (stox) Thread-Index: AQHOXhUDoUdzShJZsEWGzxmotETjV5kj1IGQ Date: Mon, 3 Jun 2013 10:58:57 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17F0F4@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stox@ietf.org" Subject: [Stox] WG Review: SIP-TO-XMPP (stox) X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 10:59:26 -0000 Hi, I have two comments concerning this charter.=20 1. The way the Objectives section is written does not make clear whether th= e current scope of stox is dully defined as making out of the draft-saintan= dre-sip-xmpp-* Proposed Standard RFCs, or whether other proposals for the s= ame mapping functionality (if submitted) will be considered.=20 2. It is very unusual that there are no proposed milestones for a document = submitted for public review. I am pretty sure that the IESG will not approv= ed the charter without seeing the milestones scheduled, so I suggest that t= hey are made public before the IESG discussion.=20 Thanks and Regards, Dan Subject: WG Review: SIP-TO-XMPP (stox) A new IETF working group has been proposed in the Real-time Applications an= d Infrastructure Area. The IESG has not made any determination yet. The fol= lowing draft charter was submitted, and is provided for informational purpo= ses only. Please send your comments to the IESG mailing list (iesg at ietf.= org) by 2013-06-10. SIP-TO-XMPP (stox) ------------------------------------------------ Current Status: Proposed WG Chairs: Markus Isomaki Yana Stamcheva Assigned Area Director: Gonzalo Camarillo Mailing list Address: stox@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stox Archive: http://www.ietf.org/mail-archive/web/stox/ Charter: Problem Statement The IETF has defined two signalling technologies that can be used for multi= media session negotiation, instant messaging, presence, file transfer, capa= bilities discovery, notifications, and other types of real-time functionali= ty: o The Session Initiation Protocol (SIP), along with various SIP extensions developed within the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group. o The Extensible Messaging and Presence Protocol (XMPP), along with various XMPP extensions developed by the IETF as well as by the XMPP Standards Foundation. SIP has been focused primarily on media session negotiation (e.g., audio an= d video), whereas XMPP has been focused primarily on messaging and presence= . As a result, the technologies are mostly complementary. However, there is also some overlap between SIP and XMPP, since there are S= IP extensions for messaging, presence, groupchat, file transfer, etc., and = there are XMPP extensions for multimedia session negotiation. This overlap has practical implications, since some deployed services use S= IP for both media and messaging/presence, whereas other deployed services u= se XMPP for both messaging/presence and media. When such services wish to = exchange information, they often need to translate their native protocol (e= ither SIP or XMPP) to the other protocol (either XMPP or SIP). Implementers needing to perform such protocol mappings have often worked ou= t their own heuristics for doing so. Unfortunately, these heuristics are n= ot always consistent, which can lead to interoperability problems. Objectives To make it easier for implementers to enable interworking between SIP-based= systems and XMPP-based systems, several Internet-Drafts have defined guide= lines for protocol mapping between SIP and XMPP, starting with draft-sainta= ndre-xmpp-simple-00 in early 2004. The current documents are: -core draft-saintandre-sip-xmpp-presence draft-saintandre-sip-xmpp-im draft-saintandre-sip-xmpp-chat draft-saintandre-sip-xmpp-groupchat draft-saintandre-sip-xmpp-media These documents are fairly stable and the authors have received feedback fr= om a number of implementers over the years. However, implementers do not a= lways know about these documents because they are Internet-Drafts and somet= imes they have become expired due to inactivity. Thus it would be helpful = to polish them off and publish them as RFCs. It might also be helpful to at some point publish additional documents in the same series, covering topics like capabilities discovery and file trans= fer. However, any such work would require a recharter. The group shall not be tasked with defining any new protocols, only with sp= ecifying mappings between existing protocols that have been defined for SIP= and XMPP. Deliverables 1. Address mapping and error handling 2. Presence mapping 3. Mapping for single instant messages 4. Mapping for one-to-one text chat sessions 5. Mapping for multi-user text= chat sessions 6. Mapping for media signaling All of the foregoing deliverables are standards track, since they are subje= ct to interoperability testing. Milestones: TBD From stpeter@stpeter.im Mon Jun 3 15:38:14 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF0A11E8105; Mon, 3 Jun 2013 15:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.794 X-Spam-Level: X-Spam-Status: No, score=-101.794 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 odirfs6WlUir; Mon, 3 Jun 2013 15:37:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 144BF11E80F9; Mon, 3 Jun 2013 15:33:04 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1C95D41234; Mon, 3 Jun 2013 16:46:08 -0600 (MDT) Message-ID: <51AD199C.8000906@stpeter.im> Date: Mon, 03 Jun 2013 16:33:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA17F0F4@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA17F0F4@AZ-FFEXMB04.global.avaya.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stox@ietf.org" , The IESG Subject: Re: [Stox] WG Review: SIP-TO-XMPP (stox) X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 22:38:14 -0000 On 6/3/13 4:58 AM, Romascanu, Dan (Dan) wrote: > Hi, > > I have two comments concerning this charter. > > 1. The way the Objectives section is written does not make clear > whether the current scope of stox is dully defined as making out of > the draft-saintandre-sip-xmpp-* Proposed Standard RFCs, or whether > other proposals for the same mapping functionality (if submitted) > will be considered. Your phrase "dully defined" is spot on: this topic is so dull that I very much doubt that other proposals will be forthcoming! However, you are right that the charter should probably say that those I-D are likely (but not certain) starting points. How about this? OLD These documents are fairly stable and the authors have received feedback from a number of implementers over the years. However, implementers do not always know about these documents because they are Internet-Drafts and sometimes they have become expired due to inactivity. Thus it would be helpful to polish them off and publish them as RFCs. NEW Those documents are fairly stable and the authors have received feedback from a number of implementers over the years. However, implementers do not always know that such mapping specifications exist, because they are Internet-Drafts and sometimes they have become expired due to inactivity. Thus it would be helpful to publish a set of mapping specifications as RFCs; the foregoing Internet-Drafts provide likely starting points, but other proposals are welcome as per normal IETF working group processes. > 2. It is very unusual that there are no proposed milestones for a > document submitted for public review. I am pretty sure that the IESG > will not approved the charter without seeing the milestones > scheduled, so I suggest that they are made public before the IESG > discussion. Personally I think that they can all be submitted for IESG review before IETF 88, and perhaps even well before that. Peter -- Peter Saint-Andre https://stpeter.im/ From dromasca@avaya.com Tue Jun 4 02:59:49 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3421D21F9A4A; Tue, 4 Jun 2013 02:59:49 -0700 (PDT) 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.550, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 thWVb5oopGJi; Tue, 4 Jun 2013 02:59:34 -0700 (PDT) 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 8406921F9774; Tue, 4 Jun 2013 01:55:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGGqrVHGmAcF/2dsb2JhbABTBoJoITC/CYECFnSCIwEBAQECARIoPwUHBAIBCA0EBAEBAQoUCQcyFAkIAgQOAwIIGodlBgGgLpxkEwSNbBR1MQcGgnFhA51/in+DD0CBZw X-IronPort-AV: E=Sophos;i="4.87,798,1363147200"; d="scan'208";a="14595183" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Jun 2013 04:55:10 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Jun 2013 04:54:03 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Tue, 4 Jun 2013 04:55:08 -0400 From: "Romascanu, Dan (Dan)" To: Peter Saint-Andre Thread-Topic: [Stox] WG Review: SIP-TO-XMPP (stox) Thread-Index: AQHOXhUDoUdzShJZsEWGzxmotETjV5kj1IGQgACiaACAAM68MA== Date: Tue, 4 Jun 2013 08:55:07 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA181116@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA17F0F4@AZ-FFEXMB04.global.avaya.com> <51AD199C.8000906@stpeter.im> In-Reply-To: <51AD199C.8000906@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "stox@ietf.org" , The IESG Subject: Re: [Stox] WG Review: SIP-TO-XMPP (stox) X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 09:59:49 -0000 Hi Peter,=20 Thank you for your answers.=20 Please see in-line.=20 Regards, Dan > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Tuesday, June 04, 2013 1:33 AM > To: Romascanu, Dan (Dan) > Cc: The IESG; stox@ietf.org > Subject: Re: [Stox] WG Review: SIP-TO-XMPP (stox) >=20 > On 6/3/13 4:58 AM, Romascanu, Dan (Dan) wrote: > > Hi, > > > > I have two comments concerning this charter. > > > > 1. The way the Objectives section is written does not make clear > > whether the current scope of stox is dully defined as making out of > > the draft-saintandre-sip-xmpp-* Proposed Standard RFCs, or whether > > other proposals for the same mapping functionality (if submitted) will > > be considered. >=20 > Your phrase "dully defined" is spot on: this topic is so dull that I > very much doubt that other proposals will be forthcoming! However, you > are right that the charter should probably say that those I-D are likely > (but not certain) starting points. >=20 > How about this? >=20 > OLD > These documents are fairly stable and the authors have received feedback > from a number of implementers over the years. However, implementers do > not always know about these documents because they are Internet-Drafts > and sometimes they have become expired due to inactivity. Thus it would > be helpful to polish them off and publish them as RFCs. >=20 > NEW > Those documents are fairly stable and the authors have received feedback > from a number of implementers over the years. However, implementers do > not always know that such mapping specifications exist, because they are > Internet-Drafts and sometimes they have become expired due to > inactivity. Thus it would be helpful to publish a set of mapping > specifications as RFCs; the foregoing Internet-Drafts provide likely > starting points, but other proposals are welcome as per normal IETF > working group processes. >=20 [[DR]] looks good > > 2. It is very unusual that there are no proposed milestones for a > > document submitted for public review. I am pretty sure that the IESG > > will not approved the charter without seeing the milestones scheduled, > > so I suggest that they are made public before the IESG discussion. >=20 > Personally I think that they can all be submitted for IESG review before > IETF 88, and perhaps even well before that. >=20 [[DR]] so October 2013 as submission date for all documents? I suggest to a= dd these to the proposed charter (unless somebody disagrees) > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ >=20 From Markus.Isomaki@nokia.com Tue Jun 4 03:47:55 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8772421F9C85; Tue, 4 Jun 2013 03:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] 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 oe9TbosWJ-95; Tue, 4 Jun 2013 03:47:41 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E2F7021F96F5; Tue, 4 Jun 2013 02:44:31 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r549iG7x005698; Tue, 4 Jun 2013 12:44:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Jun 2013 12:43:59 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.241]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0328.011; Tue, 4 Jun 2013 09:44:56 +0000 From: To: , Thread-Topic: [Stox] WG Review: SIP-TO-XMPP (stox) Thread-Index: AQHOXhUDoUdzShJZsEWGzxmotETjV5kj1IGQgADD7wCAALhBcA== Date: Tue, 4 Jun 2013 09:44:56 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA17F0F4@AZ-FFEXMB04.global.avaya.com> <51AD199C.8000906@stpeter.im> In-Reply-To: <51AD199C.8000906@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Iv70JnRaFtmvhlhLB6LU2y0+JkGPZ/gYmxa1/nsiXlzmr2gn6HkkvEOAGbKXtDElWp9bqy82zI2JCe22SrhZMK8AVKB1cEh3rUVbKcOiDTpyE3hjRxhlb6K+rdY47nWhvyApQ59VGn8Er2xsEuX9RVg350AyQDVolbmAlg0Fsi51Izk8dXgPGLj3iP02iPYAc0yMnUkwyjQIQESKTrBUcxe0ppb63eFbbvwkm2MFu6vG x-originating-ip: [172.21.82.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jun 2013 09:43:59.0197 (UTC) FILETIME=[09C6A8D0:01CE6108] X-Nokia-AV: Clean Cc: stox@ietf.org, iesg@ietf.org Subject: Re: [Stox] WG Review: SIP-TO-XMPP (stox) X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 10:47:55 -0000 Hi Dan, Peter, I agree with Peter on that there are not that many different, yet meaningfu= l, ways to do protocol mappings between SIP and XMPP. The current drafts ha= ve been around for a while and the all comments so far have been generally = positive that they are a good way to go. So, it is unlikely that we would r= eceive radically different and "competing" proposals. Having said that, I a= gree we should leave the opportunity for anyone to submit such proposals fo= r WG's consideration. I believe Peter's new charter text proposal covers th= at.=20 Markus =20 -----Original Message----- From: stox-bounces@ietf.org [mailto:stox-bounces@ietf.org] On Behalf Of ext= Peter Saint-Andre Sent: 04 June, 2013 01:33 To: Romascanu, Dan (Dan) Cc: stox@ietf.org; The IESG Subject: Re: [Stox] WG Review: SIP-TO-XMPP (stox) On 6/3/13 4:58 AM, Romascanu, Dan (Dan) wrote: > Hi, >=20 > I have two comments concerning this charter. >=20 > 1. The way the Objectives section is written does not make clear=20 > whether the current scope of stox is dully defined as making out of=20 > the draft-saintandre-sip-xmpp-* Proposed Standard RFCs, or whether=20 > other proposals for the same mapping functionality (if submitted) will=20 > be considered. Your phrase "dully defined" is spot on: this topic is so dull that I very m= uch doubt that other proposals will be forthcoming! However, you are right = that the charter should probably say that those I-D are likely (but not cer= tain) starting points. How about this? OLD These documents are fairly stable and the authors have received feedback fr= om a number of implementers over the years. However, implementers do not a= lways know about these documents because they are Internet-Drafts and somet= imes they have become expired due to inactivity. Thus it would be helpful = to polish them off and publish them as RFCs. NEW Those documents are fairly stable and the authors have received feedback fr= om a number of implementers over the years. However, implementers do not a= lways know that such mapping specifications exist, because they are Interne= t-Drafts and sometimes they have become expired due to inactivity. Thus it= would be helpful to publish a set of mapping specifications as RFCs; the f= oregoing Internet-Drafts provide likely starting points, but other proposal= s are welcome as per normal IETF working group processes. > 2. It is very unusual that there are no proposed milestones for a=20 > document submitted for public review. I am pretty sure that the IESG=20 > will not approved the charter without seeing the milestones scheduled,=20 > so I suggest that they are made public before the IESG discussion. Personally I think that they can all be submitted for IESG review before IE= TF 88, and perhaps even well before that. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ stox mailing list stox@ietf.org https://www.ietf.org/mailman/listinfo/stox From Markus.Isomaki@nokia.com Tue Jun 4 05:08:24 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD4321F9C6C for ; Tue, 4 Jun 2013 05:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.435, 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 vZGttJyqYDTn for ; Tue, 4 Jun 2013 05:08:05 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC1021F9B61 for ; Tue, 4 Jun 2013 03:45:35 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r54AjYkd030224 for ; Tue, 4 Jun 2013 13:45:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Jun 2013 13:45:47 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.241]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0328.011; Tue, 4 Jun 2013 10:46:44 +0000 From: To: Thread-Topic: sip-xmpp-core: gateway in source or destination domain? Thread-Index: Ac5hD52Ge02CBijyR0ax6yTzgradZg== Date: Tue, 4 Jun 2013 10:46:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: AUkF7AZ/aooHlqC+qifQh9tYET+5Fmw+tdxFKDvcxJh08St1TD274Idhy3OcpAFqPmakbAv8Y8mWFBoMFfKpPGrleEv/ssQ7jXmRbj5t8Apwyh9lSSlb63N+eed4pHxjqtEypMMisUQxIsJ9s2Im4fqzuwYVXFiWABURC4IClePhBWCXhZ6XDT1WCYz1y65YqqqPwnUjAac5Frguzaj+UnolD31B4u9AfyiP8gHQNFUgL5BsAQPXg9ffBzg1D7ndeNbSz89J5bDExHavnoF8Cw== x-originating-ip: [172.21.82.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jun 2013 10:45:47.0564 (UTC) FILETIME=[AC228EC0:01CE6110] X-Nokia-AV: Clean Subject: [Stox] sip-xmpp-core: gateway in source or destination domain? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 12:08:24 -0000 Hi, The sip-xmpp-core draft [1] says: "We further assume that protocol translation will occur within a gateway in the source domain, so that information generated by the user of an XMPP service will be translated by a gateway within the trust domain of that XMPP service, and information generated by the user of a SIP service will be translated by a gateway within the trust domain of that SIP service." In the context of STOX, I have a few questions about this: - Is this how the current deployments in general work? Is that enough? - Should we keep this assumption or also explicitly consider the case where= the gateway would be in the destination domain? - If we wanted to take destination-domain gateways into consideration, what= would the implications be to the mapping specs?=20 Regards, Markus=20 [1] http://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core/ From Markus.Isomaki@nokia.com Tue Jun 4 06:31:56 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEDE21F9CDC for ; Tue, 4 Jun 2013 06:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NxChADAjZO00 for ; Tue, 4 Jun 2013 06:31:42 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2B61E21F9A2F for ; Tue, 4 Jun 2013 04:59:30 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r54BwmHr011089 for ; Tue, 4 Jun 2013 14:59:29 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jun 2013 14:59:34 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.241]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0328.011; Tue, 4 Jun 2013 11:59:19 +0000 From: To: Thread-Topic: sip-xmpp-media: scope, transparency, extensibility? Thread-Index: Ac5hEd91gMqePBGKTJuHzbQj+2uuXQ== Date: Tue, 4 Jun 2013 12:00:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: AUkF7AZ/aooHlqC+qifQh1oZGlMhuIfGbzKxUtD/1r6Bf56b+50Rj1NtJIwAuByN4PL+tbol86DsqiVVK4vJ+CMPJLsujmoJVPCsHXdDsh7iUwffUP8aODGhzhEeXSa68bUKKIS30s7f9/ZqjJHDPYjx3g9mgZ14bH87ZOhYzFFtfLRLGwK5iA662At4xTL5+Ab46gbVLOuzJJ8HHofQDgCshheWime8axOSNlM2JFHlZDka9lahtlUBuxGmZKc6BH9lrRFZQIwrpVHJtKl0XQ== x-originating-ip: [172.21.82.162] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620A00461C008AM1MPN1043mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jun 2013 11:59:34.0083 (UTC) FILETIME=[FA8BC130:01CE611A] X-Nokia-AV: Clean Subject: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:31:57 -0000 --_000_E44893DD4E290745BB608EB23FDDB7620A00461C008AM1MPN1043mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A high-level comment about sip-xmpp-media [1]: SDP/Jingle Offer/Answer and ICE are moving targets by themselves. For insta= nce right now MMUSIC WG is working on new features such as "trickle-ICE" (a= dding new candidates on the fly - I know this is already supported in Jingl= e) and "bundle" (multiplexing several RTP sessions/streams into a single tr= ansport-level packet flow). We need to ensure that the sip-xmpp-media RFC-to-become is generic enough t= o stay valid even when such extensions are developed, and we have a story o= n how and where the SIP-XMPP mappings to various extensions can be develope= d if needed. For instance "bundle", AFAIK, is going to be entirely SDP/Jingle level issu= e, so presumably it will be enough that after the MMUSIC SDP spec is done, = a mapping spec to Jingle is written in XSF? On the other hand, trickle-ICE,= AFAIK, will require the use of SIP INFO (gasp! ;-) method to carry the new= candidates. That seems like something that would require an extension (" a= new RFC") to sip-xmpp-media in the IETF, explaining how Jingle's trickle i= s mapped to SIP's trickle. Regards, Markus [1] http://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-media/ --_000_E44893DD4E290745BB608EB23FDDB7620A00461C008AM1MPN1043mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A high-level comment about sip-xmpp-media [1]:<= /o:p>

 

SDP/Jingle Offer/Answer and ICE are moving targets b= y themselves. For instance right now MMUSIC WG is working on new features s= uch as “trickle-ICE” (adding new candidates on the fly – = I know this is already supported in Jingle) and “bundle” (multiplexing several RTP sessions/streams into a single transport-level p= acket flow).

 

We need to ensure that the sip-xmpp-media RFC-to-bec= ome is generic enough to stay valid even when such extensions are developed= , and we have a story on how and where the SIP-XMPP mappings to various ext= ensions can be developed if needed.

 

For instance “bundle”, AFAIK, is going t= o be entirely SDP/Jingle level issue, so presumably it will be enough that = after the MMUSIC SDP spec is done, a mapping spec to Jingle is written in X= SF? On the other hand, trickle-ICE, AFAIK, will require the use of SIP INFO (gasp! ;-) method to carry the new candidates.= That seems like something that would require an extension (“ a new R= FC”) to sip-xmpp-media in the IETF, explaining how Jingle’s tri= ckle is mapped to SIP’s trickle.  

 

Regards,

        &nbs= p;       Markus

 

[1] http://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-media/

 

 

--_000_E44893DD4E290745BB608EB23FDDB7620A00461C008AM1MPN1043mg_-- From ag@ag-projects.com Tue Jun 4 07:04:09 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F5221F91A3 for ; Tue, 4 Jun 2013 07:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, SARE_MLH_Stock1=0.87] 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 YaFcBAEfyei8 for ; Tue, 4 Jun 2013 07:03:53 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id DB0E621F9298 for ; Tue, 4 Jun 2013 05:29:41 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 9826EB35DF; Tue, 4 Jun 2013 14:29:40 +0200 (CEST) Received: from [192.168.1.6] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 6482AB00EF; Tue, 4 Jun 2013 14:29:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: Date: Tue, 4 Jun 2013 14:29:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54BE4AF3-E036-4995-B241-74CAAE804ABA@ag-projects.com> References: To: X-Mailer: Apple Mail (2.1283) Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 14:04:09 -0000 On Jun 4, 2013, at 12:46 PM, = wrote: > Hi, >=20 > The sip-xmpp-core draft [1] says: >=20 > "We further assume that protocol translation > will occur within a gateway in the source domain, so that = information > generated by the user of an XMPP service will be translated by a > gateway within the trust domain of that XMPP service, and = information > generated by the user of a SIP service will be translated by a > gateway within the trust domain of that SIP service." >=20 > In the context of STOX, I have a few questions about this: > - Is this how the current deployments in general work? Is that enough? I deployed this service and and this is how it works. It is enough in = my experience and doe snot require any new addressing scheme or location = service.=20 > - Should we keep this assumption or also explicitly consider the case = where the gateway would be in the destination domain? Not sure how one could know what gateways the foreign domain has and for = what purpose. One can only lookup DNS records for specific services like = SIP or XMPP. You do not know if they are gateways or something else. The = local domain policy can detect a remote domain capability and route = based its own policy. > - If we wanted to take destination-domain gateways into consideration, = what would the implications be to the mapping specs?=20 One can only decide what to do for its own domain and advertise it into = the DNS. One cannot guess or know about topology of a foreign domain, = can't he? Adrian > Regards, > Markus=20 >=20 > [1] http://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core/ >=20 >=20 >=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox >=20 From Markus.Isomaki@nokia.com Tue Jun 4 08:17:19 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E9721F9C91 for ; Tue, 4 Jun 2013 08:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] 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 YUjboIJMrom7 for ; Tue, 4 Jun 2013 08:17:03 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3375321F9C9D for ; Tue, 4 Jun 2013 06:24:50 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r54DNn8j007856; Tue, 4 Jun 2013 16:24:46 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jun 2013 16:24:25 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.241]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0328.011; Tue, 4 Jun 2013 13:25:22 +0000 From: To: Thread-Topic: [Stox] sip-xmpp-core: gateway in source or destination domain? Thread-Index: Ac5hD52Ge02CBijyR0ax6yTzgradZgAD45yAAAAN/2A= Date: Tue, 4 Jun 2013 13:25:22 +0000 Message-ID: References: <54BE4AF3-E036-4995-B241-74CAAE804ABA@ag-projects.com> In-Reply-To: <54BE4AF3-E036-4995-B241-74CAAE804ABA@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiOPErOR1iv9uAJoaPit0/VEI/i6KACe4vPniYq4BDDpViAo8IwBdgxXwSMBangD+nZzEPpNA7qAXHTom/25nF4DvNYPZf8BpqEBaHfCd5PEDt4rNiOv5jidfL+tD6F12yxDMrrdoODNnMx2JJMTKgtqMkSU5o6bahltmBUM7vClC3SLXkoxLYHbCgYdAEgEST0DXonnNEf4uPn48jZWiEJDNcrRwu8dyNW/1NqPz1ivkKCO6TDWASRIfF7LI+ZqXEHpO9qH06mE6pWpL0FEuaA= x-originating-ip: [172.21.82.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jun 2013 13:24:25.0570 (UTC) FILETIME=[D54F0420:01CE6126] X-Nokia-AV: Clean Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:17:19 -0000 Hi Adrian, Thanks. One clarification about your deployment: Adrian Georgescu [mailto:ag@ag-projects.com] wrote: >> - Is this how the current deployments in general work? Is that enough? > I deployed this service and and this is how it works. It is enough in my= experience and doe snot require any new addressing scheme or location serv= ice. So, when one domain runs SIP and the other domain runs XMPP, in order to ta= lk to each other, each domain is responsible for deploying a gateway that t= ranslates outgoing messages from their "native" protocol to the other proto= col? It is not enough to just deploy a gateway in one of the domains (and h= ave that domain advertise both SIP and XMPP in DNS)? Current "sip-xmpp-core" draft explicitly assumes that SIP messages are tran= slated to XMPP in the SIP domain, while XMPP messages are translated to SIP= in the XMPP domain.=20 What I was wondering is how that assumption in practice affects the draft-s= aintandre-sip-xmpp-* specs in general. To my understanding the mappings are= the same no matter in which trust domain the gateway is located. The sip-x= mpp-core does talk about the DNS operations which are certainly affected de= pending on where the translation happens.=20 Markus=20 -----Original Message----- From: ext Adrian Georgescu [mailto:ag@ag-projects.com]=20 Sent: 04 June, 2013 15:30 To: Isomaki Markus (Nokia-CIC/Espoo) Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain? On Jun 4, 2013, at 12:46 PM, wrote: > Hi, >=20 > The sip-xmpp-core draft [1] says: >=20 > "We further assume that protocol translation > will occur within a gateway in the source domain, so that information > generated by the user of an XMPP service will be translated by a > gateway within the trust domain of that XMPP service, and information > generated by the user of a SIP service will be translated by a > gateway within the trust domain of that SIP service." >=20 > In the context of STOX, I have a few questions about this: > - Is this how the current deployments in general work? Is that enough? I deployed this service and and this is how it works. It is enough in my e= xperience and doe snot require any new addressing scheme or location servic= e.=20 > - Should we keep this assumption or also explicitly consider the case whe= re the gateway would be in the destination domain? Not sure how one could know what gateways the foreign domain has and for wh= at purpose. One can only lookup DNS records for specific services like SIP = or XMPP. You do not know if they are gateways or something else. The local = domain policy can detect a remote domain capability and route based its own= policy. > - If we wanted to take destination-domain gateways into consideration, wh= at would the implications be to the mapping specs?=20 One can only decide what to do for its own domain and advertise it into the= DNS. One cannot guess or know about topology of a foreign domain, can't he= ? Adrian > Regards, > Markus=20 >=20 > [1] http://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core/ >=20 >=20 >=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox >=20 From ag@ag-projects.com Tue Jun 4 08:30:04 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31B821E80B6 for ; Tue, 4 Jun 2013 08:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, SARE_MLH_Stock1=0.87] 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 smM5g86KofcX for ; Tue, 4 Jun 2013 08:29:50 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id ED9D221F9B85 for ; Tue, 4 Jun 2013 06:36:20 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id D58EFB35DF; Tue, 4 Jun 2013 15:36:19 +0200 (CEST) Received: from ag-retina.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 509FAB017A; Tue, 4 Jun 2013 15:36:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: Date: Tue, 4 Jun 2013 15:36:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54BE4AF3-E036-4995-B241-74CAAE804ABA@ag-projects.com> To: X-Mailer: Apple Mail (2.1283) Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:30:04 -0000 On Jun 4, 2013, at 3:25 PM, wrote: > Hi Adrian, >=20 > Thanks. One clarification about your deployment: >=20 > Adrian Georgescu [mailto:ag@ag-projects.com] wrote: >=20 >>> - Is this how the current deployments in general work? Is that = enough? >=20 >> I deployed this service and and this is how it works. It is enough = in my experience and doe snot require any new addressing scheme or = location service. >=20 > So, when one domain runs SIP and the other domain runs XMPP, in order = to talk to each other, each domain is responsible for deploying a = gateway that translates outgoing messages from their "native" protocol = to the other protocol? It is not enough to just deploy a gateway in one = of the domains (and have that domain advertise both SIP and XMPP in = DNS)? >=20 > Current "sip-xmpp-core" draft explicitly assumes that SIP messages are = translated to XMPP in the SIP domain, while XMPP messages are translated = to SIP in the XMPP domain.=20 This is most likely not possible in real life because it would require = that both domains have such gateway in place and in practice the chance = of this happening is close to zero (unless adoption of such solution = goes through the roof, unlikely). Most likely the SIP/XMPP gateway is = deployed only by those who care about such interoperability, the remote = domains may not care and they should not know or be required to do = anything about this, it should just work. My use case is the following.=20 I serve SIP users and I want to provide my users with the possibility to = interact with remote XMPP domains without having to know or configure = anything in their SIP clients. For this purpose, I have configured my = SIP server to route outgoing requests for that XMPP remote domain = through the gateway I control. For receiving incoming requests from any = remote XMPP domains, I configured the proper XMPP related DNS records = to point to the same gateway (its XMPP server listening interface). This = was it works both ways and the remote XMPP domain does not need to have = a gateway not does he need to know anything about my topology or the = fact that I have a gateway, it just talks native XMPP as it would = federate with any other XMPP foreign domain. >=20 > What I was wondering is how that assumption in practice affects the = draft-saintandre-sip-xmpp-* specs in general. To my understanding the = mappings are the same no matter in which trust domain the gateway is = located. The sip-xmpp-core does talk about the DNS operations which are = certainly affected depending on where the translation happens.=20 Again, requiring both domains to have such gateway is both unnecessary = and unrealistic. Nobody can be forced to deploy a gateway just because a = foreign domain would lkike or require so. If the remote domain cares = about talking my protocol, they should deploy a gateway on their own and = it should just talk to my service natively. Adrian > Markus=20 >=20 >=20 > -----Original Message----- > From: ext Adrian Georgescu [mailto:ag@ag-projects.com]=20 > Sent: 04 June, 2013 15:30 > To: Isomaki Markus (Nokia-CIC/Espoo) > Cc: stox@ietf.org > Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination = domain? >=20 >=20 > On Jun 4, 2013, at 12:46 PM, = wrote: >=20 >> Hi, >>=20 >> The sip-xmpp-core draft [1] says: >>=20 >> "We further assume that protocol translation >> will occur within a gateway in the source domain, so that = information >> generated by the user of an XMPP service will be translated by a >> gateway within the trust domain of that XMPP service, and = information >> generated by the user of a SIP service will be translated by a >> gateway within the trust domain of that SIP service." >>=20 >> In the context of STOX, I have a few questions about this: >> - Is this how the current deployments in general work? Is that = enough? >=20 > I deployed this service and and this is how it works. It is enough in = my experience and doe snot require any new addressing scheme or location = service.=20 >=20 >> - Should we keep this assumption or also explicitly consider the case = where the gateway would be in the destination domain? >=20 > Not sure how one could know what gateways the foreign domain has and = for what purpose. One can only lookup DNS records for specific services = like SIP or XMPP. You do not know if they are gateways or something = else. The local domain policy can detect a remote domain capability and = route based its own policy. >=20 >> - If we wanted to take destination-domain gateways into = consideration, what would the implications be to the mapping specs?=20 >=20 > One can only decide what to do for its own domain and advertise it = into the DNS. One cannot guess or know about topology of a foreign = domain, can't he? >=20 > Adrian >=20 >> Regards, >> Markus=20 >>=20 >> [1] http://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> stox mailing list >> stox@ietf.org >> https://www.ietf.org/mailman/listinfo/stox >>=20 >=20 From Markus.Isomaki@nokia.com Tue Jun 4 09:53:08 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9400221F9F46 for ; Tue, 4 Jun 2013 09:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.946 X-Spam-Level: X-Spam-Status: No, score=-5.946 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] 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 doo5BAUOWaKf for ; Tue, 4 Jun 2013 09:52:54 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10921F9D32 for ; Tue, 4 Jun 2013 07:40:02 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r54EdscB011738; Tue, 4 Jun 2013 17:39:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Jun 2013 17:40:07 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.241]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0328.011; Tue, 4 Jun 2013 14:41:05 +0000 From: To: Thread-Topic: [Stox] sip-xmpp-core: gateway in source or destination domain? Thread-Index: Ac5hD52Ge02CBijyR0ax6yTzgradZgAD45yAAAAN/2AAAkS2AAAB5UzQ Date: Tue, 4 Jun 2013 14:41:05 +0000 Message-ID: References: <54BE4AF3-E036-4995-B241-74CAAE804ABA@ag-projects.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiOPErOR1iv9uAJoaPit0/VEI/i6KACe4vPniYq4BDDpViAo8IwBdgxXwSMBangD+nZzEPpNA7qAXHTom/25nF4DvNYPZf8BpqEBaHfCd5PEDt4rNiOv5jidfL+tD6F12yxDMrrdoODNnMx2JJMTKgtqMkSU5o6bahltmBUM7vClC3SLXkoxLYHbCgYdAEgEST0DXonnNEf4uPn48jZWiEJDNcrRwu8dyNW/1NqPz1ivkKCO6TDWASRIfF7LI+ZqXEHpO9qH06mE6pWpL0FEuaA= x-originating-ip: [10.163.19.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jun 2013 14:40:07.0922 (UTC) FILETIME=[68C2ED20:01CE6131] X-Nokia-AV: Clean Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:53:08 -0000 Hi Adrian, I agree with everything you say below, and that has also been my assumption= of how the deployments will work. I'm probably just reading the sip-xmpp-core too literally. If so, it would = be useful in the next update of that document to make it a bit clearer. =20 Markus=20 -----Original Message----- From: ext Adrian Georgescu [mailto:ag@ag-projects.com]=20 Sent: 04 June, 2013 16:36 To: Isomaki Markus (Nokia-CIC/Espoo) Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain? On Jun 4, 2013, at 3:25 PM, wrote: > Hi Adrian, >=20 > Thanks. One clarification about your deployment: >=20 > Adrian Georgescu [mailto:ag@ag-projects.com] wrote: >=20 >>> - Is this how the current deployments in general work? Is that enough? >=20 >> I deployed this service and and this is how it works. It is enough in m= y experience and doe snot require any new addressing scheme or location ser= vice. >=20 > So, when one domain runs SIP and the other domain runs XMPP, in order to = talk to each other, each domain is responsible for deploying a gateway that= translates outgoing messages from their "native" protocol to the other pro= tocol? It is not enough to just deploy a gateway in one of the domains (and= have that domain advertise both SIP and XMPP in DNS)? >=20 > Current "sip-xmpp-core" draft explicitly assumes that SIP messages are tr= anslated to XMPP in the SIP domain, while XMPP messages are translated to S= IP in the XMPP domain.=20 This is most likely not possible in real life because it would require that= both domains have such gateway in place and in practice the chance of this= happening is close to zero (unless adoption of such solution goes through = the roof, unlikely). Most likely the SIP/XMPP gateway is deployed only by t= hose who care about such interoperability, the remote domains may not care = and they should not know or be required to do anything about this, it shoul= d just work. My use case is the following.=20 I serve SIP users and I want to provide my users with the possibility to in= teract with remote XMPP domains without having to know or configure anythin= g in their SIP clients. For this purpose, I have configured my SIP server t= o route outgoing requests for that XMPP remote domain through the gateway I= control. For receiving incoming requests from any remote XMPP domains, I c= onfigured the proper XMPP related DNS records to point to the same gateway= (its XMPP server listening interface). This was it works both ways and the= remote XMPP domain does not need to have a gateway not does he need to kn= ow anything about my topology or the fact that I have a gateway, it just ta= lks native XMPP as it would federate with any other XMPP foreign domain. >=20 > What I was wondering is how that assumption in practice affects the draft= -saintandre-sip-xmpp-* specs in general. To my understanding the mappings a= re the same no matter in which trust domain the gateway is located. The sip= -xmpp-core does talk about the DNS operations which are certainly affected = depending on where the translation happens.=20 Again, requiring both domains to have such gateway is both unnecessary and = unrealistic. Nobody can be forced to deploy a gateway just because a foreig= n domain would lkike or require so. If the remote domain cares about talkin= g my protocol, they should deploy a gateway on their own and it should just= talk to my service natively. Adrian > Markus >=20 >=20 > -----Original Message----- > From: ext Adrian Georgescu [mailto:ag@ag-projects.com] > Sent: 04 June, 2013 15:30 > To: Isomaki Markus (Nokia-CIC/Espoo) > Cc: stox@ietf.org > Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domai= n? >=20 >=20 > On Jun 4, 2013, at 12:46 PM, wrote: >=20 >> Hi, >>=20 >> The sip-xmpp-core draft [1] says: >>=20 >> "We further assume that protocol translation will occur within a=20 >> gateway in the source domain, so that information generated by the=20 >> user of an XMPP service will be translated by a gateway within the=20 >> trust domain of that XMPP service, and information generated by the=20 >> user of a SIP service will be translated by a gateway within the=20 >> trust domain of that SIP service." >>=20 >> In the context of STOX, I have a few questions about this: >> - Is this how the current deployments in general work? Is that enough? >=20 > I deployed this service and and this is how it works. It is enough in my= experience and doe snot require any new addressing scheme or location serv= ice.=20 >=20 >> - Should we keep this assumption or also explicitly consider the case wh= ere the gateway would be in the destination domain? >=20 > Not sure how one could know what gateways the foreign domain has and for = what purpose. One can only lookup DNS records for specific services like SI= P or XMPP. You do not know if they are gateways or something else. The loca= l domain policy can detect a remote domain capability and route based its o= wn policy. >=20 >> - If we wanted to take destination-domain gateways into consideration, w= hat would the implications be to the mapping specs?=20 >=20 > One can only decide what to do for its own domain and advertise it into t= he DNS. One cannot guess or know about topology of a foreign domain, can't = he? >=20 > Adrian >=20 >> Regards, >> Markus >>=20 >> [1] http://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> stox mailing list >> stox@ietf.org >> https://www.ietf.org/mailman/listinfo/stox >>=20 >=20 From stpeter@stpeter.im Tue Jun 4 10:11:23 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AE011E80EF for ; Tue, 4 Jun 2013 10:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 P232mPpGwvgq for ; Tue, 4 Jun 2013 10:11:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9A521F8D31 for ; Tue, 4 Jun 2013 08:02:54 -0700 (PDT) Received: from sjc-vpn3-831.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 489C041240; Tue, 4 Jun 2013 09:16:01 -0600 (MDT) Message-ID: <51AE0199.2040209@stpeter.im> Date: Tue, 04 Jun 2013 09:02:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adrian Georgescu References: <54BE4AF3-E036-4995-B241-74CAAE804ABA@ag-projects.com> In-Reply-To: <54BE4AF3-E036-4995-B241-74CAAE804ABA@ag-projects.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org, "" Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:11:23 -0000 On 6/4/13 6:29 AM, Adrian Georgescu wrote: > > On Jun 4, 2013, at 12:46 PM, > wrote: > >> Hi, >> >> The sip-xmpp-core draft [1] says: >> >> "We further assume that protocol translation will occur within a >> gateway in the source domain, so that information generated by the >> user of an XMPP service will be translated by a gateway within the >> trust domain of that XMPP service, and information generated by the >> user of a SIP service will be translated by a gateway within the >> trust domain of that SIP service." >> >> In the context of STOX, I have a few questions about this: - Is >> this how the current deployments in general work? Is that enough? > > I deployed this service and and this is how it works. It is enough > in my experience and doe snot require any new addressing scheme or > location service. > >> - Should we keep this assumption or also explicitly consider the >> case where the gateway would be in the destination domain? > > Not sure how one could know what gateways the foreign domain has and > for what purpose. One can only lookup DNS records for specific > services like SIP or XMPP. You do not know if they are gateways or > something else. The local domain policy can detect a remote domain > capability and route based its own policy. Agreed. Some services / products have implemented destination-side gateways, also called connection managers. A client or peer server would connect via its preferred protocol (say, SIP) because the service advertised support for it, but the service would translate the SIP traffic into XMPP at the connection manager and natively operate using XMPP within the other parts / core of the service. A similar approach could be taken for a SIP-based system (offer an XMPP connection manager) or for a system that uses some other / proprietary protocol internally (in which case the service might have connection managers for both SIP and XMPP). But those details are service-specific and I agree with Adrian that we really can't say much about those internals, if anything. >> - If we wanted to take destination-domain gateways into >> consideration, what would the implications be to the mapping specs? >> > > One can only decide what to do for its own domain and advertise it > into the DNS. One cannot guess or know about topology of a foreign > domain, can't he? No. But I don't think we need to limit the mappings to source-side translation -- that was just a simplifying assumption we made for the sake of the examples, not an architectural recommendation. So that's something we need to make clearer in the core spec. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jun 4 10:13:24 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D42321F9BDA for ; Tue, 4 Jun 2013 10:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.834 X-Spam-Level: X-Spam-Status: No, score=-101.834 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 JTEXacmZPCpD for ; Tue, 4 Jun 2013 10:13:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6A01F21F9EC7 for ; Tue, 4 Jun 2013 08:08:47 -0700 (PDT) Received: from sjc-vpn3-831.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7352141240; Tue, 4 Jun 2013 09:21:55 -0600 (MDT) Message-ID: <51AE02FD.7000609@stpeter.im> Date: Tue, 04 Jun 2013 09:08:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adrian Georgescu References: <54BE4AF3-E036-4995-B241-74CAAE804ABA@ag-projects.com> <51AE0199.2040209@stpeter.im> In-Reply-To: <51AE0199.2040209@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org, "" Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:13:24 -0000 On 6/4/13 9:02 AM, Peter Saint-Andre wrote: > On 6/4/13 6:29 AM, Adrian Georgescu wrote: >> >> On Jun 4, 2013, at 12:46 PM, >> wrote: >> >>> Hi, >>> >>> The sip-xmpp-core draft [1] says: >>> >>> "We further assume that protocol translation will occur within a >>> gateway in the source domain, so that information generated by the >>> user of an XMPP service will be translated by a gateway within the >>> trust domain of that XMPP service, and information generated by the >>> user of a SIP service will be translated by a gateway within the >>> trust domain of that SIP service." >>> >>> In the context of STOX, I have a few questions about this: - Is >>> this how the current deployments in general work? Is that enough? >> >> I deployed this service and and this is how it works. It is enough >> in my experience and doe snot require any new addressing scheme or >> location service. >> >>> - Should we keep this assumption or also explicitly consider the >>> case where the gateway would be in the destination domain? >> >> Not sure how one could know what gateways the foreign domain has and >> for what purpose. One can only lookup DNS records for specific >> services like SIP or XMPP. You do not know if they are gateways or >> something else. The local domain policy can detect a remote domain >> capability and route based its own policy. > > Agreed. Some services / products have implemented destination-side > gateways, also called connection managers. A client or peer server would > connect via its preferred protocol (say, SIP) because the service > advertised support for it, but the service would translate the SIP > traffic into XMPP at the connection manager and natively operate using > XMPP within the other parts / core of the service. A similar approach > could be taken for a SIP-based system (offer an XMPP connection manager) > or for a system that uses some other / proprietary protocol internally > (in which case the service might have connection managers for both SIP > and XMPP). But those details are service-specific and I agree with > Adrian that we really can't say much about those internals, if anything. > >>> - If we wanted to take destination-domain gateways into >>> consideration, what would the implications be to the mapping specs? >>> >> >> One can only decide what to do for its own domain and advertise it >> into the DNS. One cannot guess or know about topology of a foreign >> domain, can't he? > > No. But I don't think we need to limit the mappings to source-side > translation -- that was just a simplifying assumption we made for the > sake of the examples, not an architectural recommendation. So that's > something we need to make clearer in the core spec. Here is proposed text. OLD This document assumes that a gateway will translate directly from one protocol to the other. We further assume that protocol translation will occur within a gateway in the source domain, so that information generated by the user of an XMPP service will be translated by a gateway within the trust domain of that XMPP service, and information generated by the user of a SIP service will be translated by a gateway within the trust domain of that SIP service. NEW This document assumes that a gateway will translate directly from one protocol to the other. For the sake of the examples, we further assume that protocol translation will occur within a gateway in the source domain, so that information generated by the user of an XMPP service will be translated by a gateway within the trust domain of that XMPP service, and information generated by the user of a SIP service will be translated by a gateway within the trust domain of that SIP service. However, nothing in this document ought to be taken as recommending against protocol translation at the destination domain. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jun 4 10:44:38 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9173821F9C56 for ; Tue, 4 Jun 2013 10:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.819 X-Spam-Level: X-Spam-Status: No, score=-101.819 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 CF5uzwICyEv7 for ; Tue, 4 Jun 2013 10:44:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9056121F9D0A for ; Tue, 4 Jun 2013 09:38:52 -0700 (PDT) Received: from sjc-vpn2-502.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 29DB441240; Tue, 4 Jun 2013 10:52:01 -0600 (MDT) Message-ID: <51AE181A.9050408@stpeter.im> Date: Tue, 04 Jun 2013 10:38:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <54BE4AF3-E036-4995-B241-74CAAE804ABA@ag-projects.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org, ag@ag-projects.com Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:44:38 -0000 On 6/4/13 7:25 AM, Markus.Isomaki@nokia.com wrote: > Current "sip-xmpp-core" draft explicitly assumes that SIP messages > are translated to XMPP in the SIP domain, while XMPP messages are > translated to SIP in the XMPP domain. Poorly phrased text. Please see my proposed fix. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jun 4 11:16:41 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228FC21F9B09; Tue, 4 Jun 2013 11:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.847 X-Spam-Level: X-Spam-Status: No, score=-101.847 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 HqtNUi2kEOdO; Tue, 4 Jun 2013 11:16:34 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A204621F99A1; Tue, 4 Jun 2013 10:33:42 -0700 (PDT) Received: from sjc-vpn2-502.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8809D41240; Tue, 4 Jun 2013 11:46:50 -0600 (MDT) Message-ID: <51AE24F3.9090404@stpeter.im> Date: Tue, 04 Jun 2013 11:33:39 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA17F0F4@AZ-FFEXMB04.global.avaya.com> <51AD199C.8000906@stpeter.im> <9904FB1B0159DA42B0B887B7FA8119CA181116@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA181116@AZ-FFEXMB04.global.avaya.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stox@ietf.org" , The IESG Subject: Re: [Stox] WG Review: SIP-TO-XMPP (stox) X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:16:41 -0000 On 6/4/13 2:55 AM, Romascanu, Dan (Dan) wrote: > Hi Peter, > > Thank you for your answers. > > Please see in-line. > > Regards, > > Dan > > > > >> -----Original Message----- >> From: Peter Saint-Andre [mailto:stpeter@stpeter.im] >> Sent: Tuesday, June 04, 2013 1:33 AM >> To: Romascanu, Dan (Dan) >> Cc: The IESG; stox@ietf.org >> Subject: Re: [Stox] WG Review: SIP-TO-XMPP (stox) >> >> On 6/3/13 4:58 AM, Romascanu, Dan (Dan) wrote: >>> Hi, >>> >>> I have two comments concerning this charter. >>> >>> 1. The way the Objectives section is written does not make clear >>> whether the current scope of stox is dully defined as making out of >>> the draft-saintandre-sip-xmpp-* Proposed Standard RFCs, or whether >>> other proposals for the same mapping functionality (if submitted) will >>> be considered. >> >> Your phrase "dully defined" is spot on: this topic is so dull that I >> very much doubt that other proposals will be forthcoming! However, you >> are right that the charter should probably say that those I-D are likely >> (but not certain) starting points. >> >> How about this? >> >> OLD >> These documents are fairly stable and the authors have received feedback >> from a number of implementers over the years. However, implementers do >> not always know about these documents because they are Internet-Drafts >> and sometimes they have become expired due to inactivity. Thus it would >> be helpful to polish them off and publish them as RFCs. >> >> NEW >> Those documents are fairly stable and the authors have received feedback >> from a number of implementers over the years. However, implementers do >> not always know that such mapping specifications exist, because they are >> Internet-Drafts and sometimes they have become expired due to >> inactivity. Thus it would be helpful to publish a set of mapping >> specifications as RFCs; the foregoing Internet-Drafts provide likely >> starting points, but other proposals are welcome as per normal IETF >> working group processes. >> > [[DR]] looks good Great. >>> 2. It is very unusual that there are no proposed milestones for a >>> document submitted for public review. I am pretty sure that the IESG >>> will not approved the charter without seeing the milestones scheduled, >>> so I suggest that they are made public before the IESG discussion. >> >> Personally I think that they can all be submitted for IESG review before >> IETF 88, and perhaps even well before that. >> > [[DR]] so October 2013 as submission date for all documents? I suggest to add these to the proposed charter (unless somebody disagrees) It might not be good to send all of the documents to the IESG at the same time. What do IESG members and the chairs think about the order? Would it make sense to hold WGLC, IETF Last Call, and IESG review about the whole bundle at the same time? I worry slightly about pushing them all through simultaneously, but I suppose the total page count is not huge (smaller than RFC 3261 or RFC 6120). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Jun 5 14:30:26 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A755821F88EA for ; Wed, 5 Jun 2013 14:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 581lWe7U2Oxo for ; Wed, 5 Jun 2013 14:30:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2951D21F88A9 for ; Wed, 5 Jun 2013 14:30:08 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 79F4B4126D; Wed, 5 Jun 2013 15:43:11 -0600 (MDT) Message-ID: <51AFADD4.9040809@stpeter.im> Date: Wed, 05 Jun 2013 15:29:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stox@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 21:30:27 -0000 On 6/4/13 6:00 AM, Markus.Isomaki@nokia.com wrote: > Hi, > > A high-level comment about sip-xmpp-media [1]: > > SDP/Jingle Offer/Answer and ICE are moving targets by themselves. For > instance right now MMUSIC WG is working on new features such as > “trickle-ICE” (adding new candidates on the fly – I know this is already > supported in Jingle) and “bundle” (multiplexing several RTP > sessions/streams into a single transport-level packet flow). > > We need to ensure that the sip-xmpp-media RFC-to-become is generic > enough to stay valid even when such extensions are developed, and we > have a story on how and where the SIP-XMPP mappings to various > extensions can be developed if needed. > > For instance “bundle”, AFAIK, is going to be entirely SDP/Jingle level > issue, so presumably it will be enough that after the MMUSIC SDP spec is > done, a mapping spec to Jingle is written in XSF? On the other hand, > trickle-ICE, AFAIK, will require the use of SIP INFO (gasp! ;-) method > to carry the new candidates. That seems like something that would > require an extension (“ a new RFC”) to sip-xmpp-media in the IETF, > explaining how Jingle’s trickle is mapped to SIP’s trickle. Markus, thanks for your comments. I've been thinking about this recently, too. I am now thinking that we might want to remove the media signaling translation from the charter. There's quite a bit of flux in this area these days, and tracking that won't be easy (e.g., do we perhaps just need a way to send SDP over XMPP?). I think we can finish all of the other charter items quickly. I'm not as convinced about "sip-xmpp-media". Peter -- Peter Saint-Andre https://stpeter.im/ From emil@sip-communicator.org Wed Jun 5 14:45:57 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D89A21F955A for ; Wed, 5 Jun 2013 14:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87] 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 tbM4it9EEOZ6 for ; Wed, 5 Jun 2013 14:45:56 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6136C21F84B2 for ; Wed, 5 Jun 2013 14:45:55 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id a11so1682644eae.26 for ; Wed, 05 Jun 2013 14:45:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=kq5ay0uJNbFU16zalr4AKQy1ERQ6ojOhzo6z/1FyYlc=; b=ZjAYHdc9xCctpLRvdFerw3EVgdkrNnOrfxQypytFcn569JI3HveJNObXkTK6BtRqHH FZM4b/jLn9W/CXfBnAiX+qGFJFrSXisXHyAJBtZUBQAeVKwbQ8025VUnjiYarmIIOXjc fqdfEoaiPZ2Q7bzKiR0qI8CCGGava7USXAq2SXuvimI5Jm+JFa9h/4wrqiHdEpPIL5Rc K3JoSHqtY1YxWZ0MROa+hzRT8+dKne6GqdLfY+Y5QaojID6vXgg6FmE7Bkxr1IQsILZe enzmY1CfaObbY6U0B9RdBV9n4YWq4ejOM0WqsOxgsHkMK5Hbs2tdHee6hoyqIz8CtGOM 0uiQ== X-Received: by 10.14.219.72 with SMTP id l48mr31125498eep.114.1370468755173; Wed, 05 Jun 2013 14:45:55 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:f028:9f4a:3fc4:f1a1]) by mx.google.com with ESMTPSA id c5sm84793157eeu.8.2013.06.05.14.45.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 14:45:54 -0700 (PDT) Message-ID: <51AFB18F.1020908@jitsi.org> Date: Wed, 05 Jun 2013 23:45:51 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn/b56i9OGISmI61czN6gZuFdH1v6VQeDTMYr/KAx+o7qkaaqunq+a65GmZTsJCzltNoOP8 Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 21:45:57 -0000 Hey Markus, On 04.06.13, 14:00, Markus.Isomaki@nokia.com wrote: > On the other hand, trickle-ICE, AFAIK, will require the use of SIP INFO > (gasp! ;-) method to carry the new candidates. Yes, but no one seems to mind and we actually seem to have rough consensus on the INFO. So I think this could be mapped relatively easily to transport-info-s Emil -- https://jitsi.org From emil@sip-communicator.org Wed Jun 5 14:49:14 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6493011E80E3 for ; Wed, 5 Jun 2013 14:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 Yl5I92tbFcg2 for ; Wed, 5 Jun 2013 14:49:13 -0700 (PDT) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5321F955A for ; Wed, 5 Jun 2013 14:49:12 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id d49so692721eek.23 for ; Wed, 05 Jun 2013 14:49:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=w9YANZsQoSFT322jjP8hlsQHnUkm0Kji1sZj97whY0c=; b=opbVR1etZ1U8Ckec3RHI/FiQFlvXEvIdS3HlE4F9fZrZl22RZ4LOcupRk8DXvcC9bs GIqdDPvS0aatEpnwXd9BwAMFvRJR0rIxskl1CGL+ZOh5xv+u+cFXUmSMHmJszuI0N5MA VXRKXkgk5HuUijxRErHON02PMrCGLppvGnUP4jFH4Dtc6eDsFWiiZYxEboUzOt1mdlFj bdFUu481zjb3f+5qMO7fV2NRgcHyu8+Z0lKwbhMTehVuq4qpYI6t5yPxXBG0LqE5G+0G AtTK2SLalHESA7fxvrwTsbVgcghmgRZDk2bQl8Tz1UvHgrzN9MnHLd+aFfsV9+ktYw7/ +MAQ== X-Received: by 10.14.109.71 with SMTP id r47mr31127550eeg.84.1370468951685; Wed, 05 Jun 2013 14:49:11 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id 3sm15036091een.7.2013.06.05.14.49.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 14:49:10 -0700 (PDT) Message-ID: <51AFB254.5080600@jitsi.org> Date: Wed, 05 Jun 2013 23:49:08 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <51AFADD4.9040809@stpeter.im> In-Reply-To: <51AFADD4.9040809@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnR5XUGNdbj0hqX1xtEw4J8OsBknvjcZuF3TIR3HTnMXKKt49Lu/8/qJC7brJJouiWvIcio Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 21:49:14 -0000 On 05.06.13, 23:29, Peter Saint-Andre wrote: > On 6/4/13 6:00 AM, Markus.Isomaki@nokia.com wrote: >> Hi, >> >> A high-level comment about sip-xmpp-media [1]: >> >> SDP/Jingle Offer/Answer and ICE are moving targets by themselves. For >> instance right now MMUSIC WG is working on new features such as >> =93trickle-ICE=94 (adding new candidates on the fly =96 I know this is= already >> supported in Jingle) and =93bundle=94 (multiplexing several RTP >> sessions/streams into a single transport-level packet flow). >> >> We need to ensure that the sip-xmpp-media RFC-to-become is generic >> enough to stay valid even when such extensions are developed, and we >> have a story on how and where the SIP-XMPP mappings to various >> extensions can be developed if needed. >> >> For instance =93bundle=94, AFAIK, is going to be entirely SDP/Jingle l= evel >> issue, so presumably it will be enough that after the MMUSIC SDP spec = is >> done, a mapping spec to Jingle is written in XSF? On the other hand, >> trickle-ICE, AFAIK, will require the use of SIP INFO (gasp! ;-) method= >> to carry the new candidates. That seems like something that would >> require an extension (=93 a new RFC=94) to sip-xmpp-media in the IETF,= >> explaining how Jingle=92s trickle is mapped to SIP=92s trickle. > > Markus, thanks for your comments. > > I've been thinking about this recently, too. I am now thinking that we > might want to remove the media signaling translation from the charter. > There's quite a bit of flux in this area these days, and tracking that > won't be easy (e.g., do we perhaps just need a way to send SDP over > XMPP?). I think we can finish all of the other charter items quickly. > I'm not as convinced about "sip-xmpp-media". Couldn't we maybe just leave this for a later milestone rather than=20 completely dropping it? People are already working on different gateways = to SIP/SDP and WebRTC and I believe that once the RTCWEB and CLUE cases=20 have been addressed, there wouldn't be that much work. Also, depending on the plan that gets chosen by RTCWEB/MMUSIC things=20 could be really simple. This would be the case with Plan B or No Plan. Cheers, Emil --=20 https://jitsi.org From stpeter@stpeter.im Wed Jun 5 14:59:26 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D25521F965A for ; Wed, 5 Jun 2013 14:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.019 X-Spam-Level: X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 29CXc3qIht-0 for ; Wed, 5 Jun 2013 14:59:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8B24921F9634 for ; Wed, 5 Jun 2013 14:59:06 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5335541265; Wed, 5 Jun 2013 16:12:18 -0600 (MDT) Message-ID: <51AFB4A7.3040103@stpeter.im> Date: Wed, 05 Jun 2013 15:59:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51AFADD4.9040809@stpeter.im> <51AFB254.5080600@jitsi.org> In-Reply-To: <51AFB254.5080600@jitsi.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 21:59:26 -0000 On 6/5/13 3:49 PM, Emil Ivov wrote: > > > On 05.06.13, 23:29, Peter Saint-Andre wrote: >> On 6/4/13 6:00 AM, Markus.Isomaki@nokia.com wrote: >>> Hi, >>> >>> A high-level comment about sip-xmpp-media [1]: >>> >>> SDP/Jingle Offer/Answer and ICE are moving targets by themselves. For >>> instance right now MMUSIC WG is working on new features such as >>> “trickle-ICE” (adding new candidates on the fly – I know this is already >>> supported in Jingle) and “bundle” (multiplexing several RTP >>> sessions/streams into a single transport-level packet flow). >>> >>> We need to ensure that the sip-xmpp-media RFC-to-become is generic >>> enough to stay valid even when such extensions are developed, and we >>> have a story on how and where the SIP-XMPP mappings to various >>> extensions can be developed if needed. >>> >>> For instance “bundle”, AFAIK, is going to be entirely SDP/Jingle level >>> issue, so presumably it will be enough that after the MMUSIC SDP spec is >>> done, a mapping spec to Jingle is written in XSF? On the other hand, >>> trickle-ICE, AFAIK, will require the use of SIP INFO (gasp! ;-) method >>> to carry the new candidates. That seems like something that would >>> require an extension (“ a new RFC”) to sip-xmpp-media in the IETF, >>> explaining how Jingle’s trickle is mapped to SIP’s trickle. >> >> Markus, thanks for your comments. >> >> I've been thinking about this recently, too. I am now thinking that we >> might want to remove the media signaling translation from the charter. >> There's quite a bit of flux in this area these days, and tracking that >> won't be easy (e.g., do we perhaps just need a way to send SDP over >> XMPP?). I think we can finish all of the other charter items quickly. >> I'm not as convinced about "sip-xmpp-media". > > Couldn't we maybe just leave this for a later milestone rather than > completely dropping it? People are already working on different gateways > to SIP/SDP and WebRTC and I believe that once the RTCWEB and CLUE cases > have been addressed, there wouldn't be that much work. > > Also, depending on the plan that gets chosen by RTCWEB/MMUSIC things > could be really simple. This would be the case with Plan B or No Plan. That's one approach. The other approach is to drop it for now, blast through the easy stuff on the charter, then recharter. Peter -- Peter Saint-Andre https://stpeter.im/ From emil@sip-communicator.org Wed Jun 5 15:06:36 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C80021F9843 for ; Wed, 5 Jun 2013 15:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87] 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 Cd8LQmkiF13y for ; Wed, 5 Jun 2013 15:06:35 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1B79321F9815 for ; Wed, 5 Jun 2013 15:06:33 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id o14so1675313eaj.21 for ; Wed, 05 Jun 2013 15:06:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=x5NgixlR/Lsx5S3jjRXbxH4Ezrq5K9IrEDjbj2+hhYM=; b=XMVpBwea2RDi1YBVHUIOaw0vBqC/KQnXVGMpTpAJNJuhh80XT66TH7vfx/bTBKJp95 0j83DQFrs53vgNOJbbwxXqM+M/mXQ4QJJzbUQiXof4g0qjWqZiEfptYe5ICF4zNbUQ5B U/6stKY3bsXRojqUPSq560OZU3k7FdmNim7U7Yhnq88LpG6Is6/ihCUNXZe3edfUHAgp iNegvKFuYcCEeQkEbo1iMO8inoleSWGu/RgOk/KYVvEk2d3q29EecGPn0rC8jI0mM2IU symMPc12qb0b8pFJhsf0BqBKp+bBFbM63b5wrRmnTRiJ7h4xwbZM+XBMGevT5uLK8/x0 6QyA== X-Received: by 10.14.98.71 with SMTP id u47mr31037476eef.12.1370469990395; Wed, 05 Jun 2013 15:06:30 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:f028:9f4a:3fc4:f1a1]) by mx.google.com with ESMTPSA id y10sm100451852eev.3.2013.06.05.15.06.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 15:06:29 -0700 (PDT) Message-ID: <51AFB663.3020405@jitsi.org> Date: Thu, 06 Jun 2013 00:06:27 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <51AFADD4.9040809@stpeter.im> <51AFB254.5080600@jitsi.org> <51AFB4A7.3040103@stpeter.im> In-Reply-To: <51AFB4A7.3040103@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlchx/xAXAVObBzMZTDUcyaQ5J4tT8v1atqKVXkljpnxOdOQWcBg4I6IpuVEuv52vxQZ//C Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:06:36 -0000 On 05.06.13, 23:59, Peter Saint-Andre wrote: > On 6/5/13 3:49 PM, Emil Ivov wrote: >> >> >> On 05.06.13, 23:29, Peter Saint-Andre wrote: >>> On 6/4/13 6:00 AM, Markus.Isomaki@nokia.com wrote: >>>> Hi, >>>> >>>> A high-level comment about sip-xmpp-media [1]: >>>> >>>> SDP/Jingle Offer/Answer and ICE are moving targets by themselves. Fo= r >>>> instance right now MMUSIC WG is working on new features such as >>>> =93trickle-ICE=94 (adding new candidates on the fly =96 I know this = is already >>>> supported in Jingle) and =93bundle=94 (multiplexing several RTP >>>> sessions/streams into a single transport-level packet flow). >>>> >>>> We need to ensure that the sip-xmpp-media RFC-to-become is generic >>>> enough to stay valid even when such extensions are developed, and we= >>>> have a story on how and where the SIP-XMPP mappings to various >>>> extensions can be developed if needed. >>>> >>>> For instance =93bundle=94, AFAIK, is going to be entirely SDP/Jingle= level >>>> issue, so presumably it will be enough that after the MMUSIC SDP spe= c is >>>> done, a mapping spec to Jingle is written in XSF? On the other hand,= >>>> trickle-ICE, AFAIK, will require the use of SIP INFO (gasp! ;-) meth= od >>>> to carry the new candidates. That seems like something that would >>>> require an extension (=93 a new RFC=94) to sip-xmpp-media in the IET= F, >>>> explaining how Jingle=92s trickle is mapped to SIP=92s trickle. >>> >>> Markus, thanks for your comments. >>> >>> I've been thinking about this recently, too. I am now thinking that w= e >>> might want to remove the media signaling translation from the charter= =2E >>> There's quite a bit of flux in this area these days, and tracking tha= t >>> won't be easy (e.g., do we perhaps just need a way to send SDP over >>> XMPP?). I think we can finish all of the other charter items quickly.= >>> I'm not as convinced about "sip-xmpp-media". >> >> Couldn't we maybe just leave this for a later milestone rather than >> completely dropping it? People are already working on different gatewa= ys >> to SIP/SDP and WebRTC and I believe that once the RTCWEB and CLUE case= s >> have been addressed, there wouldn't be that much work. >> >> Also, depending on the plan that gets chosen by RTCWEB/MMUSIC things >> could be really simple. This would be the case with Plan B or No Plan.= > > That's one approach. The other approach is to drop it for now, blast > through the easy stuff on the charter, then recharter. I'd appreciate a couple of pointers about IETF best practices here. Is there something wrong with a dormant WG? Is this considered bad=20 practice and generally avoided? Because if not, wouldn't it be easier to blast through the easy=20 milestones then wait until ready to start work on the SDP translation.=20 This way, once we are ready we won't have to go through the hassle of=20 mustering consensus, finding victims for chairs, rechartering and most=20 importantly: thinking of a new name! Emil --=20 https://jitsi.org From stpeter@stpeter.im Wed Jun 5 15:15:58 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF44421F8F38 for ; Wed, 5 Jun 2013 15:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.947 X-Spam-Level: X-Spam-Status: No, score=-101.947 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 40DC0MsTvS3W for ; Wed, 5 Jun 2013 15:15:53 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 646CD21E804C for ; Wed, 5 Jun 2013 15:15:53 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 401C141266; Wed, 5 Jun 2013 16:29:03 -0600 (MDT) Message-ID: <51AFB894.4010203@stpeter.im> Date: Wed, 05 Jun 2013 16:15:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51AFADD4.9040809@stpeter.im> <51AFB254.5080600@jitsi.org> <51AFB4A7.3040103@stpeter.im> <51AFB663.3020405@jitsi.org> In-Reply-To: <51AFB663.3020405@jitsi.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:15:58 -0000 On 6/5/13 4:06 PM, Emil Ivov wrote: > > > On 05.06.13, 23:59, Peter Saint-Andre wrote: >> On 6/5/13 3:49 PM, Emil Ivov wrote: >>> >>> >>> On 05.06.13, 23:29, Peter Saint-Andre wrote: >>>> On 6/4/13 6:00 AM, Markus.Isomaki@nokia.com wrote: >>>>> Hi, >>>>> >>>>> A high-level comment about sip-xmpp-media [1]: >>>>> >>>>> SDP/Jingle Offer/Answer and ICE are moving targets by themselves. For >>>>> instance right now MMUSIC WG is working on new features such as >>>>> “trickle-ICE” (adding new candidates on the fly – I know this is >>>>> already >>>>> supported in Jingle) and “bundle” (multiplexing several RTP >>>>> sessions/streams into a single transport-level packet flow). >>>>> >>>>> We need to ensure that the sip-xmpp-media RFC-to-become is generic >>>>> enough to stay valid even when such extensions are developed, and we >>>>> have a story on how and where the SIP-XMPP mappings to various >>>>> extensions can be developed if needed. >>>>> >>>>> For instance “bundle”, AFAIK, is going to be entirely SDP/Jingle level >>>>> issue, so presumably it will be enough that after the MMUSIC SDP >>>>> spec is >>>>> done, a mapping spec to Jingle is written in XSF? On the other hand, >>>>> trickle-ICE, AFAIK, will require the use of SIP INFO (gasp! ;-) method >>>>> to carry the new candidates. That seems like something that would >>>>> require an extension (“ a new RFC”) to sip-xmpp-media in the IETF, >>>>> explaining how Jingle’s trickle is mapped to SIP’s trickle. >>>> >>>> Markus, thanks for your comments. >>>> >>>> I've been thinking about this recently, too. I am now thinking that we >>>> might want to remove the media signaling translation from the charter. >>>> There's quite a bit of flux in this area these days, and tracking that >>>> won't be easy (e.g., do we perhaps just need a way to send SDP over >>>> XMPP?). I think we can finish all of the other charter items quickly. >>>> I'm not as convinced about "sip-xmpp-media". >>> >>> Couldn't we maybe just leave this for a later milestone rather than >>> completely dropping it? People are already working on different gateways >>> to SIP/SDP and WebRTC and I believe that once the RTCWEB and CLUE cases >>> have been addressed, there wouldn't be that much work. >>> >>> Also, depending on the plan that gets chosen by RTCWEB/MMUSIC things >>> could be really simple. This would be the case with Plan B or No Plan. >> >> That's one approach. The other approach is to drop it for now, blast >> through the easy stuff on the charter, then recharter. > > I'd appreciate a couple of pointers about IETF best practices here. > > Is there something wrong with a dormant WG? Is this considered bad > practice and generally avoided? > > Because if not, wouldn't it be easier to blast through the easy > milestones then wait until ready to start work on the SDP translation. > This way, once we are ready we won't have to go through the hassle of > mustering consensus, finding victims for chairs, rechartering and most > importantly: thinking of a new name! The IESG likes to see progress. If the WG quickly finishes its other milestones, then rechartering to do the media mapping would be fairly straightforward. Peter -- Peter Saint-Andre https://stpeter.im/ From emil@sip-communicator.org Wed Jun 5 15:20:43 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516A721F8AD5 for ; Wed, 5 Jun 2013 15:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87] 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 DiJm0FAlI8ow for ; Wed, 5 Jun 2013 15:20:42 -0700 (PDT) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id E1C8D21F8A0B for ; Wed, 5 Jun 2013 15:20:37 -0700 (PDT) Received: by mail-ea0-f177.google.com with SMTP id j14so1735800eak.22 for ; Wed, 05 Jun 2013 15:20:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=0eDaVwjp17Rscd1JXqK2XjLMit1Pcrcrf9Dn0Sw1hQ4=; b=AuMcEUFfAlE5tYYG1Ampm7Jq/qLjEpogFMcNDRcnu/veDl8HAoE8xZbB3OpRn07iSK jETlTCx/swOez9kii84pghrPa+rJjH0XsL1j+IvFE7I03pQ9rXZuYbkdc+CFuVWMY141 dUVk1v1mOb49Ueb/Ie1iDqvS6H/T0+Ifb4XlMUat57vDgvxD71Qqb6+nxIOQlTu0+u3v D6MFMxYUtKLd13UgmRShc01hrFpknf55j0NdrbL+yvwf6UhSXcN5jvgFQJgSt64C4N7u 1sIQQAYc/IDA9/7UtzhWcwaTttbutHYvrbSouhTrxq70HPZXN4umkeT4IPT4LH+Iop2Q qpeQ== X-Received: by 10.15.32.142 with SMTP id a14mr30397167eev.152.1370470836741; Wed, 05 Jun 2013 15:20:36 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:f028:9f4a:3fc4:f1a1]) by mx.google.com with ESMTPSA id m45sm10392001eeu.17.2013.06.05.15.20.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 15:20:36 -0700 (PDT) Message-ID: <51AFB9B2.9070008@jitsi.org> Date: Thu, 06 Jun 2013 00:20:34 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <51AFADD4.9040809@stpeter.im> <51AFB254.5080600@jitsi.org> <51AFB4A7.3040103@stpeter.im> <51AFB663.3020405@jitsi.org> <51AFB894.4010203@stpeter.im> In-Reply-To: <51AFB894.4010203@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl2AI4RYXtnV/4085xRO1Mj5Ia9fBb8dt3C2A97DsRXFKugckG7Ey7WxQK9rRWc1JYnIL9v Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 22:20:43 -0000 On 06.06.13, 00:15, Peter Saint-Andre wrote: > On 6/5/13 4:06 PM, Emil Ivov wrote: >> >> >> On 05.06.13, 23:59, Peter Saint-Andre wrote: >>> On 6/5/13 3:49 PM, Emil Ivov wrote: >>>> >>>> >>>> On 05.06.13, 23:29, Peter Saint-Andre wrote: >>>>> On 6/4/13 6:00 AM, Markus.Isomaki@nokia.com wrote: >>>>>> Hi, >>>>>> >>>>>> A high-level comment about sip-xmpp-media [1]: >>>>>> >>>>>> SDP/Jingle Offer/Answer and ICE are moving targets by themselves. = For >>>>>> instance right now MMUSIC WG is working on new features such as >>>>>> =93trickle-ICE=94 (adding new candidates on the fly =96 I know thi= s is >>>>>> already >>>>>> supported in Jingle) and =93bundle=94 (multiplexing several RTP >>>>>> sessions/streams into a single transport-level packet flow). >>>>>> >>>>>> We need to ensure that the sip-xmpp-media RFC-to-become is generic= >>>>>> enough to stay valid even when such extensions are developed, and = we >>>>>> have a story on how and where the SIP-XMPP mappings to various >>>>>> extensions can be developed if needed. >>>>>> >>>>>> For instance =93bundle=94, AFAIK, is going to be entirely SDP/Jing= le level >>>>>> issue, so presumably it will be enough that after the MMUSIC SDP >>>>>> spec is >>>>>> done, a mapping spec to Jingle is written in XSF? On the other han= d, >>>>>> trickle-ICE, AFAIK, will require the use of SIP INFO (gasp! ;-) me= thod >>>>>> to carry the new candidates. That seems like something that would >>>>>> require an extension (=93 a new RFC=94) to sip-xmpp-media in the I= ETF, >>>>>> explaining how Jingle=92s trickle is mapped to SIP=92s trickle. >>>>> >>>>> Markus, thanks for your comments. >>>>> >>>>> I've been thinking about this recently, too. I am now thinking that= we >>>>> might want to remove the media signaling translation from the chart= er. >>>>> There's quite a bit of flux in this area these days, and tracking t= hat >>>>> won't be easy (e.g., do we perhaps just need a way to send SDP over= >>>>> XMPP?). I think we can finish all of the other charter items quickl= y. >>>>> I'm not as convinced about "sip-xmpp-media". >>>> >>>> Couldn't we maybe just leave this for a later milestone rather than >>>> completely dropping it? People are already working on different gate= ways >>>> to SIP/SDP and WebRTC and I believe that once the RTCWEB and CLUE ca= ses >>>> have been addressed, there wouldn't be that much work. >>>> >>>> Also, depending on the plan that gets chosen by RTCWEB/MMUSIC things= >>>> could be really simple. This would be the case with Plan B or No Pla= n. >>> >>> That's one approach. The other approach is to drop it for now, blast >>> through the easy stuff on the charter, then recharter. >> >> I'd appreciate a couple of pointers about IETF best practices here. >> >> Is there something wrong with a dormant WG? Is this considered bad >> practice and generally avoided? >> >> Because if not, wouldn't it be easier to blast through the easy >> milestones then wait until ready to start work on the SDP translation.= >> This way, once we are ready we won't have to go through the hassle of >> mustering consensus, finding victims for chairs, rechartering and most= >> importantly: thinking of a new name! > > The IESG likes to see progress. If the WG quickly finishes its other > milestones, then rechartering to do the media mapping would be fairly > straightforward. OK, I see. Emil --=20 https://jitsi.org From saul@ag-projects.com Thu Jun 6 00:29:02 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD99A21F9640 for ; Thu, 6 Jun 2013 00:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] 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 E8vaDZYzu33D for ; Thu, 6 Jun 2013 00:28:58 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B9A7121F9635 for ; Thu, 6 Jun 2013 00:28:54 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 6FF69B35E1; Thu, 6 Jun 2013 09:28:53 +0200 (CEST) Received: from [192.168.1.35] (106.Red-83-57-1.dynamicIP.rima-tde.net [83.57.1.106]) by mail.sipthor.net (Postfix) with ESMTPSA id 16BF8B35DC; Thu, 6 Jun 2013 09:28:40 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <51AFADD4.9040809@stpeter.im> Date: Thu, 6 Jun 2013 09:28:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <511FFF21-1711-4BC1-BFA5-887EF177B82B@ag-projects.com> References: <51AFADD4.9040809@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 07:29:03 -0000 Hi, On Jun 5, 2013, at 11:29 PM, Peter Saint-Andre = wrote: > On 6/4/13 6:00 AM, Markus.Isomaki@nokia.com wrote: >> Hi, >>=20 >> A high-level comment about sip-xmpp-media [1]: >>=20 >> SDP/Jingle Offer/Answer and ICE are moving targets by themselves. For >> instance right now MMUSIC WG is working on new features such as >> =93trickle-ICE=94 (adding new candidates on the fly =96 I know this = is already >> supported in Jingle) and =93bundle=94 (multiplexing several RTP >> sessions/streams into a single transport-level packet flow). >>=20 >> We need to ensure that the sip-xmpp-media RFC-to-become is generic >> enough to stay valid even when such extensions are developed, and we >> have a story on how and where the SIP-XMPP mappings to various >> extensions can be developed if needed. >>=20 >> For instance =93bundle=94, AFAIK, is going to be entirely SDP/Jingle = level >> issue, so presumably it will be enough that after the MMUSIC SDP spec = is >> done, a mapping spec to Jingle is written in XSF? On the other hand, >> trickle-ICE, AFAIK, will require the use of SIP INFO (gasp! ;-) = method >> to carry the new candidates. That seems like something that would >> require an extension (=93 a new RFC=94) to sip-xmpp-media in the = IETF, >> explaining how Jingle=92s trickle is mapped to SIP=92s trickle. =20 >=20 > Markus, thanks for your comments. >=20 > I've been thinking about this recently, too. I am now thinking that we > might want to remove the media signaling translation from the charter. > There's quite a bit of flux in this area these days, and tracking that > won't be easy (e.g., do we perhaps just need a way to send SDP over > XMPP?). I think we can finish all of the other charter items quickly. > I'm not as convinced about "sip-xmpp-media". >=20 Those are all new things mainly pushed by WebRTC which is also a moving = target at this point IMHO. XEP-0176 already specifies a way to tell endpoints that they should use = the "legacy" offer/answer model and not send candidates in a = session-info [0]. The XEP actually mentions it in the context of a SIP - = XMPP gateway. Moreover, Emil and I already have working and = interoperable implementations using this mechanism, FWIW. Could we perhaps have sip-xmpp-media be the base spec which uses the = RFC3264 model and later extend it with ICE trickle and friends, or is = that a no go? [0]: http://xmpp.org/extensions/xep-0176.html#support-sdp -- Sa=FAl Ibarra Corretg=E9 AG Projects From emcho@sip-communicator.org Thu Jun 6 00:36:03 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2664021F9704 for ; Thu, 6 Jun 2013 00:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] 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 jGj+gfZrTZ2U for ; Thu, 6 Jun 2013 00:35:49 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3351821F96EB for ; Thu, 6 Jun 2013 00:35:49 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v10so2986719pde.18 for ; Thu, 06 Jun 2013 00:35:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=dA+PNJZt7TObuq5A4bElxqTXdBKBObDuAIR4sAuinUY=; b=hU7b81czvVHjZsv55j7xGKd6FGWcHMoKPjiDkGO9T6oZB9WygWUARe2o3EmTuBwkTM r/QtexhjAl4SRhinvPpSr0IOOmVmzz5Qlg16mN3jnGcVha4UnkIDeJiL+QchEfH4V1T4 zDKUWEINP5V712IjiQmnIjfupzhiQs4zT++9YSEL0ojPsvN5ub+kwxW5C3QiM1tLjxyZ TU3oqFUNqrk5vgxAxlQH7md1xfbWHmyS/Cih17JvAfF33MIMfMH8gpDlyCiM1b9LjhGI j2y67ovcXwfTP6qjiXhltySXParqLvLTAfxcdDS/0FoKqEh8C38Lfd7X5NiC5GpWuJmZ 1Rgg== X-Received: by 10.68.178.66 with SMTP id cw2mr36886454pbc.47.1370504148927; Thu, 06 Jun 2013 00:35:48 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by mx.google.com with ESMTPSA id qi1sm76454954pac.21.2013.06.06.00.35.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 00:35:48 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id q11so2981269pdj.10 for ; Thu, 06 Jun 2013 00:35:48 -0700 (PDT) X-Received: by 10.68.189.36 with SMTP id gf4mr37542023pbc.73.1370504148198; Thu, 06 Jun 2013 00:35:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.192.65 with HTTP; Thu, 6 Jun 2013 00:35:28 -0700 (PDT) In-Reply-To: <511FFF21-1711-4BC1-BFA5-887EF177B82B@ag-projects.com> References: <51AFADD4.9040809@stpeter.im> <511FFF21-1711-4BC1-BFA5-887EF177B82B@ag-projects.com> From: Emil Ivov Date: Thu, 6 Jun 2013 09:35:28 +0200 Message-ID: To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmsz7FTB0/kOtypVuuexzUEsetPvp6cW3FvOo7FA9yF3/SPx881qPzQfo+AwRvSZZrghxgm Cc: stox@ietf.org, Peter Saint-Andre Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 07:36:03 -0000 +1 On Thu, Jun 6, 2013 at 9:28 AM, Sa=FAl Ibarra Corretg=E9 wrote: > Hi, > > On Jun 5, 2013, at 11:29 PM, Peter Saint-Andre wrote= : > >> On 6/4/13 6:00 AM, Markus.Isomaki@nokia.com wrote: >>> Hi, >>> >>> A high-level comment about sip-xmpp-media [1]: >>> >>> SDP/Jingle Offer/Answer and ICE are moving targets by themselves. For >>> instance right now MMUSIC WG is working on new features such as >>> =93trickle-ICE=94 (adding new candidates on the fly =96 I know this is = already >>> supported in Jingle) and =93bundle=94 (multiplexing several RTP >>> sessions/streams into a single transport-level packet flow). >>> >>> We need to ensure that the sip-xmpp-media RFC-to-become is generic >>> enough to stay valid even when such extensions are developed, and we >>> have a story on how and where the SIP-XMPP mappings to various >>> extensions can be developed if needed. >>> >>> For instance =93bundle=94, AFAIK, is going to be entirely SDP/Jingle le= vel >>> issue, so presumably it will be enough that after the MMUSIC SDP spec i= s >>> done, a mapping spec to Jingle is written in XSF? On the other hand, >>> trickle-ICE, AFAIK, will require the use of SIP INFO (gasp! ;-) method >>> to carry the new candidates. That seems like something that would >>> require an extension (=93 a new RFC=94) to sip-xmpp-media in the IETF, >>> explaining how Jingle=92s trickle is mapped to SIP=92s trickle. >> >> Markus, thanks for your comments. >> >> I've been thinking about this recently, too. I am now thinking that we >> might want to remove the media signaling translation from the charter. >> There's quite a bit of flux in this area these days, and tracking that >> won't be easy (e.g., do we perhaps just need a way to send SDP over >> XMPP?). I think we can finish all of the other charter items quickly. >> I'm not as convinced about "sip-xmpp-media". >> > > Those are all new things mainly pushed by WebRTC which is also a moving t= arget at this point IMHO. > > XEP-0176 already specifies a way to tell endpoints that they should use t= he "legacy" offer/answer model and not send candidates in a session-info [0= ]. The XEP actually mentions it in the context of a SIP - XMPP gateway. Mor= eover, Emil and I already have working and interoperable implementations us= ing this mechanism, FWIW. > > Could we perhaps have sip-xmpp-media be the base spec which uses the RFC3= 264 model and later extend it with ICE trickle and friends, or is that a no= go? > > > [0]: http://xmpp.org/extensions/xep-0176.html#support-sdp > > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects > > > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox --=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 Markus.Isomaki@nokia.com Thu Jun 6 07:25:59 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D852221F99B7 for ; Thu, 6 Jun 2013 07:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 cK1uZqSBmyw6 for ; Thu, 6 Jun 2013 07:25:27 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC4D21F99E0 for ; Thu, 6 Jun 2013 07:24:40 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r56EOT7L015442; Thu, 6 Jun 2013 17:24:30 +0300 Received: from vaebh106.NOE.Nokia.com ([10.160.244.32]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jun 2013 17:24:29 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Jun 2013 17:24:28 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.114]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0328.011; Thu, 6 Jun 2013 14:24:28 +0000 From: To: , Thread-Topic: [Stox] sip-xmpp-media: scope, transparency, extensibility? Thread-Index: Ac5hEd91gMqePBGKTJuHzbQj+2uuXQBIfNYAABTo8oAAB6VdYA== Date: Thu, 6 Jun 2013 14:25:44 +0000 Message-ID: References: <51AFADD4.9040809@stpeter.im> <511FFF21-1711-4BC1-BFA5-887EF177B82B@ag-projects.com> In-Reply-To: <511FFF21-1711-4BC1-BFA5-887EF177B82B@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiOPErOR1iv9uAJoaPit0/WPFoeEBhXB1mUIVlD3o/TA4AuOMP6eW9S82V7yMrgPi0/xDIYYpT68LjUlEMmOLqx9ti/0WgI/06ZhgltgTx7u1XF3Yfj8HMQ3ztyNgOoZkE5EFtzFREnByxzb3Gw/VphvBzIp04tVSQ1vmuzb527asZxxLECn87/9Ukeoct77jPmrIL4bDehs+VyycBI10ebDeOUV+NJ6YwSFiExAeNecHY3shd7pox4EKDVkShWYQw== x-originating-ip: [172.21.82.124] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2013 14:24:28.0882 (UTC) FILETIME=[8DE04B20:01CE62C1] X-Nokia-AV: Clean Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:25:59 -0000 Hi Saul, > Could we perhaps have sip-xmpp-media be the base spec which uses the RFC3= 264 model and later extend it with ICE trickle and friends, or is that a no= go? Yes, that could be a good approach, and that was what I was also initially = thinking. We just need to make sure that the scope of the baseline sip-xmpp= -media is clear, and have a clean enough extensibility model for it, and go= od enough guidance on how the gateways can deal with a) feature disparity b= etween SIP and XMPP clients they serve and b) features unknown to the gatew= ay itself. I suppose it would be anyway a good idea to write somewhere some= thing about the transparency or non-transparency of SIP-XMPP gateways wrt. = new features. For instance a SIP proxy can - in theory - be fairly transpar= ent to many types of new features (new headers, new header parameters, new = payloads), but it is much harder to do that in a gateway.=20 Markus =20 -----Original Message----- From: stox-bounces@ietf.org [mailto:stox-bounces@ietf.org] On Behalf Of ext= Sa=FAl Ibarra Corretg=E9 Sent: 06 June, 2013 10:29 To: Peter Saint-Andre Cc: stox@ietf.org Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? Hi, On Jun 5, 2013, at 11:29 PM, Peter Saint-Andre wrote: > On 6/4/13 6:00 AM, Markus.Isomaki@nokia.com wrote: >> Hi, >>=20 >> A high-level comment about sip-xmpp-media [1]: >>=20 >> SDP/Jingle Offer/Answer and ICE are moving targets by themselves. For=20 >> instance right now MMUSIC WG is working on new features such as=20 >> "trickle-ICE" (adding new candidates on the fly - I know this is=20 >> already supported in Jingle) and "bundle" (multiplexing several RTP=20 >> sessions/streams into a single transport-level packet flow). >>=20 >> We need to ensure that the sip-xmpp-media RFC-to-become is generic=20 >> enough to stay valid even when such extensions are developed, and we=20 >> have a story on how and where the SIP-XMPP mappings to various=20 >> extensions can be developed if needed. >>=20 >> For instance "bundle", AFAIK, is going to be entirely SDP/Jingle=20 >> level issue, so presumably it will be enough that after the MMUSIC=20 >> SDP spec is done, a mapping spec to Jingle is written in XSF? On the=20 >> other hand, trickle-ICE, AFAIK, will require the use of SIP INFO=20 >> (gasp! ;-) method to carry the new candidates. That seems like=20 >> something that would require an extension (" a new RFC") to=20 >> sip-xmpp-media in the IETF, explaining how Jingle's trickle is mapped to= SIP's trickle. >=20 > Markus, thanks for your comments. >=20 > I've been thinking about this recently, too. I am now thinking that we=20 > might want to remove the media signaling translation from the charter. > There's quite a bit of flux in this area these days, and tracking that=20 > won't be easy (e.g., do we perhaps just need a way to send SDP over=20 > XMPP?). I think we can finish all of the other charter items quickly. > I'm not as convinced about "sip-xmpp-media". >=20 Those are all new things mainly pushed by WebRTC which is also a moving tar= get at this point IMHO. XEP-0176 already specifies a way to tell endpoints that they should use the= "legacy" offer/answer model and not send candidates in a session-info [0].= The XEP actually mentions it in the context of a SIP - XMPP gateway. Moreo= ver, Emil and I already have working and interoperable implementations usin= g this mechanism, FWIW. Could we perhaps have sip-xmpp-media be the base spec which uses the RFC326= 4 model and later extend it with ICE trickle and friends, or is that a no g= o? [0]: http://xmpp.org/extensions/xep-0176.html#support-sdp -- Sa=FAl Ibarra Corretg=E9 AG Projects _______________________________________________ stox mailing list stox@ietf.org https://www.ietf.org/mailman/listinfo/stox From stpeter@stpeter.im Fri Jun 7 12:32:35 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A51C21F9347 for ; Fri, 7 Jun 2013 12:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.233 X-Spam-Level: X-Spam-Status: No, score=-100.233 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_DNS_FOR_FROM=1.496, SARE_MLH_Stock1=0.87, 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 GazvE31uivo3 for ; Fri, 7 Jun 2013 12:32:30 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DAF6821F8EF7 for ; Fri, 7 Jun 2013 12:32:00 -0700 (PDT) Received: from ergon.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5873B4127E; Fri, 7 Jun 2013 13:44:49 -0600 (MDT) Message-ID: <51B23511.4080209@stpeter.im> Date: Fri, 07 Jun 2013 13:31:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <51AFADD4.9040809@stpeter.im> <511FFF21-1711-4BC1-BFA5-887EF177B82B@ag-projects.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org, saul@ag-projects.com Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 19:32:35 -0000 On 6/6/13 8:25 AM, Markus.Isomaki@nokia.com wrote: > Hi Saul, > >> Could we perhaps have sip-xmpp-media be the base spec which uses the RFC3264 model and later extend it with ICE trickle and friends, or is that a no go? > > Yes, that could be a good approach, and that was what I was also initially thinking. We just need to make sure that the scope of the baseline sip-xmpp-media is clear, and have a clean enough extensibility model for it, and good enough guidance on how the gateways can deal with a) feature disparity between SIP and XMPP clients they serve and b) features unknown to the gateway itself. I suppose it would be anyway a good idea to write somewhere something about the transparency or non-transparency of SIP-XMPP gateways wrt. new features. For instance a SIP proxy can - in theory - be fairly transparent to many types of new features (new headers, new header parameters, new payloads), but it is much harder to do that in a gateway. Maybe I'll leave it up to Saúl and Emil to write that I-D. :-) Peter -- Peter Saint-Andre https://stpeter.im/ From emil@sip-communicator.org Fri Jun 7 12:37:33 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA4221F9925 for ; Fri, 7 Jun 2013 12:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87] 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 SqfwuRsJFi2F for ; Fri, 7 Jun 2013 12:37:32 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id C9E0821F9920 for ; Fri, 7 Jun 2013 12:37:31 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi5so1648508wib.2 for ; Fri, 07 Jun 2013 12:37:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=lCOycjBn11WhL+qa8xSW1h6ucM35cXKsMhIBwPcIr5Q=; b=kcTf+G2FgUlIdKuoRTbdnrTWl/IRjmPohjt3Sm4dUH32A5RnY2giNxmJS7BUMYVZoX qLN2X+gQ9PyfUuNNmSP/fEExZo7JZFHabY4q2p4sdfLvwUqEH/I49lUwptVGoJorNcAy 93GP1DnzdIRCliUbemDM0La7OeO41b9dTDehnzCJzLDoclzFdPz7bfLQFVmYkihLIUfm 4QStkPXc6bNZhYP7Zqw6FVbf2rxWLQSDhYnu67w0VgbyrjQviLetUXgi6VbeRlDWkt9z pbEXG6k/9TkYRF9QoxZJiEoA+aznobOdMXlsKvDZ6Ez90jDJ9J6F9nANiTSvF8Rq5tTc Puwg== X-Received: by 10.180.188.97 with SMTP id fz1mr85345wic.34.1370633850226; Fri, 07 Jun 2013 12:37:30 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:705b:5a3b:224:adee]) by mx.google.com with ESMTPSA id fx7sm24228448wic.11.2013.06.07.12.37.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Jun 2013 12:37:29 -0700 (PDT) Message-ID: <51B23678.1010905@jitsi.org> Date: Fri, 07 Jun 2013 21:37:28 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Peter Saint-Andre References: <51AFADD4.9040809@stpeter.im> <511FFF21-1711-4BC1-BFA5-887EF177B82B@ag-projects.com> <51B23511.4080209@stpeter.im> In-Reply-To: <51B23511.4080209@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm2uowmWo5hVOoFLw950jqO5n2O7Xn8TVOFHOsb96b4AokCXby3dr9bSG0Xdib1A1ETycuI Cc: stox@ietf.org, saul@ag-projects.com, Markus.Isomaki@nokia.com Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 19:37:33 -0000 On 07.06.13, 21:31, Peter Saint-Andre wrote: > On 6/6/13 8:25 AM, Markus.Isomaki@nokia.com wrote: >> Hi Saul, >> >>> Could we perhaps have sip-xmpp-media be the base spec which uses the = RFC3264 model and later extend it with ICE trickle and friends, or is tha= t a no go? >> >> Yes, that could be a good approach, and that was what I was also initi= ally thinking. We just need to make sure that the scope of the baseline s= ip-xmpp-media is clear, and have a clean enough extensibility model for i= t, and good enough guidance on how the gateways can deal with a) feature = disparity between SIP and XMPP clients they serve and b) features unknown= to the gateway itself. I suppose it would be anyway a good idea to write= somewhere something about the transparency or non-transparency of SIP-XM= PP gateways wrt. new features. For instance a SIP proxy can - in theory -= be fairly transparent to many types of new features (new headers, new he= ader parameters, new payloads), but it is much harder to do that in a gat= eway. > > Maybe I'll leave it up to Sa=FAl and Emil to write that I-D. :-) Yeah, that should teach them! ;) Personally I don't mind helping up, so sure, count me in! Sa=FAl already = has implemented a Jingle gateway, so we should probably be fine if we=20 just documented that. Emil --=20 https://jitsi.org From stpeter@stpeter.im Fri Jun 7 12:40:56 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEFD21F9958 for ; Fri, 7 Jun 2013 12:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.981 X-Spam-Level: X-Spam-Status: No, score=-100.981 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 coobWgfQjOkL for ; Fri, 7 Jun 2013 12:40:50 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CA44221F9956 for ; Fri, 7 Jun 2013 12:40:50 -0700 (PDT) Received: from ergon.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1D45B4127E; Fri, 7 Jun 2013 13:54:09 -0600 (MDT) Message-ID: <51B23740.7080801@stpeter.im> Date: Fri, 07 Jun 2013 13:40:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Emil Ivov References: <51AFADD4.9040809@stpeter.im> <511FFF21-1711-4BC1-BFA5-887EF177B82B@ag-projects.com> <51B23511.4080209@stpeter.im> <51B23678.1010905@jitsi.org> In-Reply-To: <51B23678.1010905@jitsi.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org, saul@ag-projects.com, Markus.Isomaki@nokia.com Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 19:40:56 -0000 On 6/7/13 1:37 PM, Emil Ivov wrote: > > > On 07.06.13, 21:31, Peter Saint-Andre wrote: >> On 6/6/13 8:25 AM, Markus.Isomaki@nokia.com wrote: >>> Hi Saul, >>> >>>> Could we perhaps have sip-xmpp-media be the base spec which uses the >>>> RFC3264 model and later extend it with ICE trickle and friends, or >>>> is that a no go? >>> >>> Yes, that could be a good approach, and that was what I was also >>> initially thinking. We just need to make sure that the scope of the >>> baseline sip-xmpp-media is clear, and have a clean enough >>> extensibility model for it, and good enough guidance on how the >>> gateways can deal with a) feature disparity between SIP and XMPP >>> clients they serve and b) features unknown to the gateway itself. I >>> suppose it would be anyway a good idea to write somewhere something >>> about the transparency or non-transparency of SIP-XMPP gateways wrt. >>> new features. For instance a SIP proxy can - in theory - be fairly >>> transparent to many types of new features (new headers, new header >>> parameters, new payloads), but it is much harder to do that in a >>> gateway. >> >> Maybe I'll leave it up to Saúl and Emil to write that I-D. :-) > > Yeah, that should teach them! ;) > > Personally I don't mind helping up, so sure, count me in! Saúl already > has implemented a Jingle gateway, so we should probably be fine if we > just documented that. Sure, these mapping specs are mostly just documenting what folks are already doing in their gateway implementations. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Jun 11 10:04:48 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09FB21F8F15; Tue, 11 Jun 2013 10:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.089 X-Spam-Level: X-Spam-Status: No, score=-102.089 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 7uhm-+qWX+oP; Tue, 11 Jun 2013 10:04:44 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B823621F88A9; Tue, 11 Jun 2013 10:04:44 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6423E40393; Tue, 11 Jun 2013 11:18:15 -0600 (MDT) Message-ID: <51B758A9.10006@stpeter.im> Date: Tue, 11 Jun 2013 11:04:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "stox@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: The IESG Subject: [Stox] revised STOX charter proposal X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 17:04:49 -0000 Based on feedback received on the stox@ietf.org list and from IESG members, here is a revised charter proposal for the STOX WG. Your feedback is welcome. Peter ### SIP-TO-XMPP (stox) ------------------------------------------------ Current Status: Proposed WG Chairs: Markus Isomaki Yana Stamcheva Assigned Area Director: Gonzalo Camarillo Mailing list Address: stox at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stox Archive: http://www.ietf.org/mail-archive/web/stox/ Charter: Problem Statement The IETF has defined two signalling technologies that can be used for multimedia session negotiation, instant messaging, presence, file transfer, capabilities discovery, notifications, and other types of real-time functionality: o The Session Initiation Protocol (SIP), along with various SIP extensions developed within the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group. o The Extensible Messaging and Presence Protocol (XMPP), along with various XMPP extensions developed by the IETF as well as by the XMPP Standards Foundation. SIP has been focused primarily on media session negotiation (e.g., audio and video), whereas XMPP has been focused primarily on messaging and presence. As a result, the technologies are mostly complementary. However, there is also some overlap between SIP and XMPP, since there are SIP extensions for messaging, presence, groupchat, file transfer, etc., and there are XMPP extensions for multimedia session negotiation. This overlap has practical implications, since some deployed services use SIP for both media and messaging/presence, whereas other deployed services use XMPP for both messaging/presence and media. When such services wish to exchange information, they often need to translate their native protocol (either SIP or XMPP) to the other protocol (either XMPP or SIP). Implementers needing to perform such protocol mappings have often worked out their own heuristics for doing so. Unfortunately, these heuristics are not always consistent, which can lead to interoperability problems. Objectives To make it easier for implementers to enable interworking between SIP-based systems and XMPP-based systems, several Internet-Drafts have defined guidelines for protocol mapping between SIP and XMPP, starting with draft-saintandre-xmpp-simple-00 in early 2004. The current documents are: draft-saintandre-sip-xmpp-core draft-saintandre-sip-xmpp-presence draft-saintandre-sip-xmpp-im draft-saintandre-sip-xmpp-chat draft-saintandre-sip-xmpp-groupchat draft-saintandre-sip-xmpp-media Those documents are fairly stable and the authors have received feedback from a number of implementers over the years. However, implementers do not always know that such mapping specifications exist, because they are Internet-Drafts and sometimes they have become expired due to inactivity. Thus it would be helpful to publish a set of mapping specifications as RFCs; the foregoing Internet-Drafts provide likely starting points, but other proposals are welcome as per normal IETF working group processes. It might also be helpful to at some point publish additional documents in the same series, covering topics like capabilities discovery and file transfer. However, any such work would require a recharter. The group shall not be tasked with defining any new protocols, only with specifying mappings between existing protocols that have been defined for SIP and XMPP. Deliverables 1. Address mapping and error handling 2. Presence mapping 3. Mapping for single instant messages 4. Mapping for one-to-one text chat sessions 5. Mapping for multi-user text chat sessions 6. Mapping for media signaling All of the foregoing deliverables are standards track, since they are subject to interoperability testing. Milestones: Jun 2013 Accept starting-point mapping specifications as WG items Aug 2013 Start Working Group Last Call on mapping specifications Oct 2013 Submit mapping specifications to the IESG ### From Markus.Isomaki@nokia.com Wed Jun 12 23:57:04 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7083C21F93D7 for ; Wed, 12 Jun 2013 23:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.729 X-Spam-Level: X-Spam-Status: No, score=-3.729 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] 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 eTjjrpK4oj7E for ; Wed, 12 Jun 2013 23:56:58 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 922B421F85F4 for ; Wed, 12 Jun 2013 23:56:58 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5D6ugoV020032; Thu, 13 Jun 2013 09:56:51 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.49]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Jun 2013 09:56:50 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.114]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.02.0328.011; Thu, 13 Jun 2013 06:58:19 +0000 From: To: , Thread-Topic: [Stox] sip-xmpp-media: scope, transparency, extensibility? Thread-Index: Ac5hEd91gMqePBGKTJuHzbQj+2uuXQBIfNYAABTo8oAAB6VdYABD49+AAAA1fwAAAB3OAAEStu2Q Date: Thu, 13 Jun 2013 06:56:49 +0000 Message-ID: References: <51AFADD4.9040809@stpeter.im> <511FFF21-1711-4BC1-BFA5-887EF177B82B@ag-projects.com> <51B23511.4080209@stpeter.im> <51B23678.1010905@jitsi.org> <51B23740.7080801@stpeter.im> In-Reply-To: <51B23740.7080801@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IiOPErOR1iv9uAJoaPit0/WPFoeEBhXB1mUIVlD3o/TA4AuOMP6eW9S82V7yMrgPi0/xDIYYpT68LjUlEMmOLqx9ti/0WgI/06ZhgltgTx7u1XF3Yfj8HMQ3ztyNgOoZkE5EFtzFREnByxzb3Gw/VphvBzIp04tVSQ1vmuzb527asZxxLECn87/9Ukeoct77jPmrIL4bDehs+VyycBI10ebDeOUV+NJ6YwSFiExAeNecHY3shd7pox4EKDVkShWYQw== x-originating-ip: [172.21.81.172] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jun 2013 06:56:50.0710 (UTC) FILETIME=[2E0CBB60:01CE6803] X-Nokia-AV: Clean Cc: stox@ietf.org, saul@ag-projects.com Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 06:57:04 -0000 Hi, Peter Saint-Andre [mailto:stpeter@stpeter.im] wrote:=20 > >On 6/7/13 1:37 PM, Emil Ivov wrote: >>=20 >>=20 >> Yeah, that should teach them! ;) >>=20 >> Personally I don't mind helping up, so sure, count me in! Sa=FAl already= =20 >> has implemented a Jingle gateway, so we should probably be fine if we=20 >> just documented that. > >Sure, these mapping specs are mostly just documenting what folks are alrea= dy doing in their gateway implementations. > And I don't think either it needs to be more complicated than that. Just tr= y to document the scope of the gateway's mapping capabilities as well as po= ssible, and think about how we can later on extend them to support new feat= ures. The real-time media is the most interesting part in this sense. And indeed, it's good to have volunteer co-authors for STOX documents.=20 Markus=20 From ietf-secretariat-reply@ietf.org Thu Jun 13 09:23:24 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0134521F9A2A for ; Thu, 13 Jun 2013 09:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.102 X-Spam-Level: X-Spam-Status: No, score=-102.102 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87, 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 OT28-ce3RuRE for ; Thu, 13 Jun 2013 09:23:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D9221F9A52 for ; Thu, 13 Jun 2013 09:23:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: stox@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130613162323.5146.46354.idtracker@ietfa.amsl.com> Date: Thu, 13 Jun 2013 09:23:23 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 13 Jun 2013 09:48:52 -0700 Subject: [Stox] Milestones changed for stox WG X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 16:23:24 -0000 Added milestone "Accept starting-point mapping specifications as WG items", due June 2013. Added milestone "Start Working Group Last Call on mapping specifications", due August 2013. Added milestone "Submit mapping specifications to the IESG", due October 2013. URL: http://datatracker.ietf.org/wg/stox/charter/ From stpeter@stpeter.im Thu Jun 13 20:53:18 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA1821F9703 for ; Thu, 13 Jun 2013 20:53:18 -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 srbmL9udSvIY for ; Thu, 13 Jun 2013 20:53:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8EE21F96F5 for ; Thu, 13 Jun 2013 20:53:01 -0700 (PDT) Received: from sjc-vpn2-327.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 178E24127A; Thu, 13 Jun 2013 22:06:39 -0600 (MDT) Message-ID: <51BA9398.7030800@stpeter.im> Date: Thu, 13 Jun 2013 21:52:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "stox@ietf.org" References: <20130614034950.23702.85444.idtracker@ietfa.amsl.com> In-Reply-To: <20130614034950.23702.85444.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130614034950.23702.85444.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Stox] Fwd: I-D Action: draft-saintandre-sip-xmpp-core-05.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 03:53:18 -0000 FYI. This version incorporates feedback from Markus. Peter -------- Original Message -------- Subject: I-D Action: draft-saintandre-sip-xmpp-core-05.txt Date: Thu, 13 Jun 2013 20:49:50 -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 : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Addresses and Error Conditions Author(s) : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-saintandre-sip-xmpp-core-05.txt Pages : 14 Date : 2013-06-13 Abstract: As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-core There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-saintandre-sip-xmpp-core-05 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 From stpeter@stpeter.im Thu Jun 13 21:28:36 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F14D21E805A for ; Thu, 13 Jun 2013 21:28:36 -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 hy47wQoNoAi9 for ; Thu, 13 Jun 2013 21:28:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CB8A411E80D5 for ; Thu, 13 Jun 2013 21:28:31 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1AD634127A; Thu, 13 Jun 2013 22:42:10 -0600 (MDT) Message-ID: <51BA9BED.1020300@stpeter.im> Date: Thu, 13 Jun 2013 22:28:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "stox@ietf.org" References: <20130614042540.17904.61539.idtracker@ietfa.amsl.com> In-Reply-To: <20130614042540.17904.61539.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130614042540.17904.61539.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Stox] Fwd: I-D Action: draft-saintandre-sip-xmpp-chat-06.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 04:28:36 -0000 FYI. Fixes to many of the examples and a few of the mapping tables. Peter -------- Original Message -------- Subject: I-D Action: draft-saintandre-sip-xmpp-chat-06.txt Date: Thu, 13 Jun 2013 21:25:40 -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 : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Author(s) : Peter Saint-Andre Salvatore Loreto Eddy Gavita Nazin Hossain Filename : draft-saintandre-sip-xmpp-chat-06.txt Pages : 13 Date : 2013-06-13 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-chat There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-chat-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-saintandre-sip-xmpp-chat-06 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 From saul@ag-projects.com Fri Jun 14 00:32:59 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BD221F9AEC for ; Fri, 14 Jun 2013 00:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] 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 uCoTul8mCRdF for ; Fri, 14 Jun 2013 00:32:53 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC7F21F938E for ; Fri, 14 Jun 2013 00:32:50 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 51622B35E0; Fri, 14 Jun 2013 09:32:49 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id BE3DBB017C for ; Fri, 14 Jun 2013 09:32:48 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1085) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <51AE02FD.7000609@stpeter.im> Date: Fri, 14 Jun 2013 09:32:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54BE4AF3-E036-4995-B241-74CAAE804ABA@ag-projects.com> <51AE0199.2040209@stpeter.im> <51AE02FD.7000609@stpeter.im> To: stox@ietf.org X-Mailer: Apple Mail (2.1085) Subject: Re: [Stox] sip-xmpp-core: gateway in source or destination domain? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 07:32:59 -0000 >=20 > Here is proposed text. >=20 > OLD > This document assumes that a gateway will translate directly from = one > protocol to the other. We further assume that protocol translation > will occur within a gateway in the source domain, so that = information > generated by the user of an XMPP service will be translated by a > gateway within the trust domain of that XMPP service, and = information > generated by the user of a SIP service will be translated by a > gateway within the trust domain of that SIP service. >=20 > NEW > This document assumes that a gateway will translate directly from = one > protocol to the other. For the sake of the examples, we further > assume that protocol translation will occur within a gateway in the > source domain, so that information generated by the user of an XMPP > service will be translated by a gateway within the trust domain of > that XMPP service, and information generated by the user of a SIP > service will be translated by a gateway within the trust domain of > that SIP service. However, nothing in this document ought to be > taken as recommending against protocol translation at the = destination > domain. >=20 +1. -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Fri Jun 14 00:36:40 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8728D21F9B85 for ; Fri, 14 Jun 2013 00:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] 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 kFezLm80DOzA for ; Fri, 14 Jun 2013 00:36:34 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A316F21F9B80 for ; Fri, 14 Jun 2013 00:36:34 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 126EEB35E0; Fri, 14 Jun 2013 09:36:33 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id A010FB017C; Fri, 14 Jun 2013 09:36:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <51B23511.4080209@stpeter.im> Date: Fri, 14 Jun 2013 09:36:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D7F73FF-2264-4990-A36E-8B8327681CD2@ag-projects.com> References: <51AFADD4.9040809@stpeter.im> <511FFF21-1711-4BC1-BFA5-887EF177B82B@ag-projects.com> <51B23511.4080209@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1085) Cc: stox@ietf.org, Markus.Isomaki@nokia.com Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 07:36:40 -0000 On Jun 7, 2013, at 9:31 PM, Peter Saint-Andre wrote: > On 6/6/13 8:25 AM, Markus.Isomaki@nokia.com wrote: >> Hi Saul, >>=20 >>> Could we perhaps have sip-xmpp-media be the base spec which uses the = RFC3264 model and later extend it with ICE trickle and friends, or is = that a no go? >>=20 >> Yes, that could be a good approach, and that was what I was also = initially thinking. We just need to make sure that the scope of the = baseline sip-xmpp-media is clear, and have a clean enough extensibility = model for it, and good enough guidance on how the gateways can deal with = a) feature disparity between SIP and XMPP clients they serve and b) = features unknown to the gateway itself. I suppose it would be anyway a = good idea to write somewhere something about the transparency or = non-transparency of SIP-XMPP gateways wrt. new features. For instance a = SIP proxy can - in theory - be fairly transparent to many types of new = features (new headers, new header parameters, new payloads), but it is = much harder to do that in a gateway.=20 >=20 > Maybe I'll leave it up to Sa=FAl and Emil to write that I-D. :-) >=20 Sorry, catching up... Sure, I already volunteered to do this and I still = plan to :-) Basically, as Emil said down below it would start as a description of = what we ended up implementing and then try to iron out (some of) the = problems we found along the way. -- Sa=FAl Ibarra Corretg=E9 AG Projects From stpeter@stpeter.im Fri Jun 14 05:28:17 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D785021F9BC9 for ; Fri, 14 Jun 2013 05:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.014 X-Spam-Level: X-Spam-Status: No, score=-102.014 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87, 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 I96CNMsekgPW for ; Fri, 14 Jun 2013 05:28:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9573021F9BF4 for ; Fri, 14 Jun 2013 05:28:11 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 460F241278; Fri, 14 Jun 2013 06:41:52 -0600 (MDT) Message-ID: <51BB0C5C.5020806@stpeter.im> Date: Fri, 14 Jun 2013 06:28:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <51AFADD4.9040809@stpeter.im> <511FFF21-1711-4BC1-BFA5-887EF177B82B@ag-projects.com> <51B23511.4080209@stpeter.im> <2D7F73FF-2264-4990-A36E-8B8327681CD2@ag-projects.com> In-Reply-To: <2D7F73FF-2264-4990-A36E-8B8327681CD2@ag-projects.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org, Markus.Isomaki@nokia.com Subject: Re: [Stox] sip-xmpp-media: scope, transparency, extensibility? X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 12:28:18 -0000 On 6/14/13 1:36 AM, Saúl Ibarra Corretgé wrote: > > On Jun 7, 2013, at 9:31 PM, Peter Saint-Andre wrote: > >> On 6/6/13 8:25 AM, Markus.Isomaki@nokia.com wrote: >>> Hi Saul, >>> >>>> Could we perhaps have sip-xmpp-media be the base spec which uses the RFC3264 model and later extend it with ICE trickle and friends, or is that a no go? >>> >>> Yes, that could be a good approach, and that was what I was also initially thinking. We just need to make sure that the scope of the baseline sip-xmpp-media is clear, and have a clean enough extensibility model for it, and good enough guidance on how the gateways can deal with a) feature disparity between SIP and XMPP clients they serve and b) features unknown to the gateway itself. I suppose it would be anyway a good idea to write somewhere something about the transparency or non-transparency of SIP-XMPP gateways wrt. new features. For instance a SIP proxy can - in theory - be fairly transparent to many types of new features (new headers, new header parameters, new payloads), but it is much harder to do that in a gateway. >> >> Maybe I'll leave it up to Saúl and Emil to write that I-D. :-) >> > > Sorry, catching up... Sure, I already volunteered to do this and I still plan to :-) > > Basically, as Emil said down below it would start as a description of what we ended up implementing and then try to iron out (some of) the problems we found along the way. Great. If you're able to use parts of draft-saintandre-sip-xmpp-media as a starting point, feel free! Peter -- Peter Saint-Andre https://stpeter.im/ From iesg-secretary@ietf.org Fri Jun 14 08:58:22 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6287E21F9CF6; Fri, 14 Jun 2013 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.083 X-Spam-Level: X-Spam-Status: No, score=-102.083 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87, 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 22fN6HDfOKs9; Fri, 14 Jun 2013 08:58:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A85B821F9CF9; Fri, 14 Jun 2013 08:58:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130614155821.11370.2796.idtracker@ietfa.amsl.com> Date: Fri, 14 Jun 2013 08:58:21 -0700 Cc: stox WG , stpeter@stpeter.im Subject: [Stox] WG Action: Formed SIP-TO-XMPP (stox) X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 15:58:22 -0000 A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information please contact the Area Directors or the WG Chairs. SIP-TO-XMPP (stox) ------------------------------------------------ Current Status: Proposed WG Chairs: Markus Isomaki Yana Stamcheva Assigned Area Director: Gonzalo Camarillo Mailing list Address: stox@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stox Archive: http://www.ietf.org/mail-archive/web/stox/ Charter: Problem Statement The IETF has defined two signalling technologies that can be used for multimedia session negotiation, instant messaging, presence, file transfer, capabilities discovery, notifications, and other types of real-time functionality: o The Session Initiation Protocol (SIP), along with various SIP extensions developed within the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group. o The Extensible Messaging and Presence Protocol (XMPP), along with various XMPP extensions developed by the IETF as well as by the XMPP Standards Foundation. SIP has been focused primarily on media session negotiation (e.g., audio and video), whereas XMPP has been focused primarily on messaging and presence. As a result, the technologies are mostly complementary. However, there is also some overlap between SIP and XMPP, since there are SIP extensions for messaging, presence, groupchat, file transfer, etc., and there are XMPP extensions for multimedia session negotiation. This overlap has practical implications, since some deployed services use SIP for both media and messaging/presence, whereas other deployed services use XMPP for both messaging/presence and media. When such services wish to exchange information, they often need to translate their native protocol (either SIP or XMPP) to the other protocol (either XMPP or SIP). Implementers needing to perform such protocol mappings have often worked out their own heuristics for doing so. Unfortunately, these heuristics are not always consistent, which can lead to interoperability problems. Objectives To make it easier for implementers to enable interworking between SIP-based systems and XMPP-based systems, several Internet-Drafts have defined guidelines for protocol mapping between SIP and XMPP, starting with draft-saintandre-xmpp-simple-00 in early 2004. The current documents are: draft-saintandre-sip-xmpp-core draft-saintandre-sip-xmpp-presence draft-saintandre-sip-xmpp-im draft-saintandre-sip-xmpp-chat draft-saintandre-sip-xmpp-groupchat draft-saintandre-sip-xmpp-media Those documents are fairly stable and the authors have received feedback from a number of implementers over the years. However, implementers do not always know that such mapping specifications exist, because they are Internet-Drafts and sometimes they have become expired due to inactivity. Thus it would be helpful to publish a set of mapping specifications as RFCs; the foregoing Internet-Drafts provide likely starting points, but other proposals are welcome as per normal IETF working group processes. It might also be helpful to at some point publish additional documents in the same series, covering topics like capabilities discovery and file transfer. However, any such work would require a recharter. The group shall not be tasked with defining any new protocols, only with specifying mappings between existing protocols that have been defined for SIP and XMPP. Deliverables 1. Address mapping and error handling 2. Presence mapping 3. Mapping for single instant messages 4. Mapping for one-to-one text chat sessions 5. Mapping for multi-user text chat sessions 6. Mapping for media signaling All of the foregoing deliverables are standards track, since they are subject to interoperability testing. Milestones: Jun 2013 Accept starting-point mapping specifications as WG items Aug 2013 Start Working Group Last Call on mapping specifications Oct 2013 Submit mapping specifications to the IESG From ietf-secretariat-reply@ietf.org Fri Jun 14 08:59:29 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B24721F9D04 for ; Fri, 14 Jun 2013 08:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.095 X-Spam-Level: X-Spam-Status: No, score=-102.095 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87, 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 pyOiT9y+ddyJ for ; Fri, 14 Jun 2013 08:59:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 083BA21F9D09 for ; Fri, 14 Jun 2013 08:59:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: stox@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130614155916.24860.778.idtracker@ietfa.amsl.com> Date: Fri, 14 Jun 2013 08:59:16 -0700 From: IETF Secretariat Subject: [Stox] Milestones changed for stox WG X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 15:59:29 -0000 Added milestone "Accept starting-point mapping specifications as WG items", due June 2013. Added milestone "Start Working Group Last Call on mapping specifications", due August 2013. Added milestone "Submit mapping specifications to the IESG", due October 2013. URL: http://datatracker.ietf.org/wg/stox/charter/ From Markus.Isomaki@nokia.com Wed Jun 19 02:57:42 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7682421F9D62 for ; Wed, 19 Jun 2013 02:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.729 X-Spam-Level: X-Spam-Status: No, score=-4.729 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] 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 L3wI15HNZWXo for ; Wed, 19 Jun 2013 02:57:37 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD1421F9F8D for ; Wed, 19 Jun 2013 02:57:31 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5J9vUWW012758; Wed, 19 Jun 2013 12:57:30 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Jun 2013 12:57:29 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.114]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0328.011; Wed, 19 Jun 2013 09:57:29 +0000 From: To: Thread-Topic: STOX WG officially approved - charter and work plan Thread-Index: Ac5s0sc0tX7Ng9OBQgewER3C/WEoug== Date: Wed, 19 Jun 2013 09:57:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: 2PrCjJ7f5poVv9TjWbkmkscUh3Yam0/0GqsaftD1c+FvEmpo0Q6v0IjlcLoDQQzEBOdkYiqks4bZmDJvjQhhEDNw2npo5p5bcfxoLi2CEGoJrmYvjzQPqJ8UiUTa5HV/enB0rGvYgBFeW5f5FhPf+Vp8Tal/VWSJyBomJLt6E+P3L9QCU4ZdXUYyrCp6MUCX/U+c2ZLA+W7Ywxc4Y1Z7zkVuvFAHbnZxp72d5tol58bE6iVlKm/i9KhOZu0auwJOT/p4db4yLNB4sflphEOvuw== x-originating-ip: [172.21.80.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2013 09:57:29.0963 (UTC) FILETIME=[6939FBB0:01CE6CD3] X-Nokia-AV: Clean Cc: yana@jitsi.org Subject: [Stox] STOX WG officially approved - charter and work plan X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 09:57:42 -0000 Hi all, The SIP-to-XMPP (STOX) WG has now been officially approved by the IESG. Our= charter can be found at . My= self (markus.isomaki@nokia.com) and Yana Stamcheva (yana@jitsi.org) will ac= t as co-chairs.=20 The plan outlined in the charter is that this will be a focused and relativ= ely straight-forward effort that we aim to finish in just a few months. The= charter has these milestones: Jun 2013 Accept starting-point mapping specifications as WG items Aug 2013 Start Working Group Last Call on mapping specifications Oct 2013 Submit mapping specifications to the IESG Yana and I have additionally outlined a bit more detailed plan: - June: One week consensus call on adopting the current drafts as WG items. - Latest by July 8: Submit current drafts as -00 WG drafts. - July: Ask people to comment and raise open issues about the drafts, ask c= o-authors to prepare presentations about open issues for IETF 87. Start rec= ruiting reviewers and if needed, co-authors.=20 - IETF 87: Meet for 1 hour. Discuss open issues. Agree on the deadline for= reviews and WG last call on the documents. Decide if all documents can pro= ceed in the same timeline, or whether some phasing will be needed.=20 - By end of August: Start the official WG last call.=20 - September - October: Process last call comments and finalize the document= s for the IESG review.=20 - IETF 88: Meet if there is interest and energy to discuss about recharteri= ng, i.e. adding new WG items. Let us know if you have any feedback to this. I will next send a few mails to the list about specific topics such as our = first milestone, i.e. the acceptance of the current drafts as WG items. Markus=20 From Markus.Isomaki@nokia.com Wed Jun 19 03:30:40 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFDD21F9F84 for ; Wed, 19 Jun 2013 03:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[AWL=1.102, 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 D0iydyG1c1kO for ; Wed, 19 Jun 2013 03:30:34 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3053921F9F83 for ; Wed, 19 Jun 2013 03:30:32 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5JAURZW009996 for ; Wed, 19 Jun 2013 13:30:27 +0300 Received: from vaebh106.NOE.Nokia.com ([10.160.244.32]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jun 2013 13:30:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Jun 2013 13:30:27 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.114]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0328.011; Wed, 19 Jun 2013 10:32:06 +0000 From: To: Thread-Topic: Consensus call: Adopting the "current" drafts as WG documents to match the planned deliverables Thread-Index: Ac5s06sZm7uVB/G4RuKwD/tyQ77Ung== Date: Wed, 19 Jun 2013 10:30:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: wMRUUUZB6NdpUEshuhzL9VYxQ4oabMbMtJENXSl6bta9UjrtiyYak0NjxmNOG78mvPuw0QzB751ECopgMsfl7FsewLbOu7Knglgmur5TzlzEFvrF5ltP/UX0bw3f41rntDt/6DTq4LEpChcfk0wnxPU5nKAqHGxYh3FFeFrh3uFeNhNUCT4qGz7oLSJAdRbcExAdw12iTfvuNXnn4VM8iPPZjddV0wfn/YwQN3JFhuz9swkFMmFdpmIm4/7Hv9Jp9buAdbNHn80bXXg9V0rPoDPgZo4EvHHb+eR2f/2EB5vUt2mS/P6sD2ULc7IRDbV1 x-originating-ip: [172.21.80.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2013 10:30:27.0565 (UTC) FILETIME=[03F819D0:01CE6CD8] X-Nokia-AV: Clean Subject: [Stox] Consensus call: Adopting the "current" drafts as WG documents to match the planned deliverables X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 10:30:40 -0000 Hi, The chartered deliverables of STOX are: 1. Address mapping and error handling 2. Presence mapping 3. Mapping for single instant messages 4. Mapping for one-to-one text chat sessions 5. Mapping for multi-user text chat sessions 6. Mapping for media signaling The plan is that a separate RFC will be published for each of these.=20 As the SIP-to-XMPP mapping effort has been going on for some years already = even before the WG for it has been setup, we already have a set of relative= ly mature (individual) drafts to match these deliverables: draft-saintandre-sip-xmpp-core (Peter Saint-Andre, Avshalom Houri, Joe Hild= ebrand) draft-saintandre-sip-xmpp-presence (Peter Saint-Andre, Avshalom Houri, Joe = Hildebrand) draft-saintandre-sip-xmpp-im (Peter Saint-Andre, Avshalom Houri, Joe Hildeb= rand) draft-saintandre-sip-xmpp-chat (Peter Saint-Andre, Salvatore Loreto, Eddy G= avita, Nazin Hossain) draft-saintandre-sip-xmpp-groupchat (Peter Saint-Andre, Salvatore Loreto, S= aul Ibarra Corretge, Fabio Forno) draft-saintandre-sip-xmpp-media (Peter Saint-Andre) The first milestone of our charter is: Jun 2013 Accept starting-point mapping specifications as WG items To meet this on time, we are hereby starting a consensus call on adopting t= hese drafts as WG items, so that they can be submitted as such by the IETF = 87 -00 cut-off date (July 8). So, please send your comments on this to the = STOX list by the end of next week (June 30), after which the chairs determi= ne if there is a consensus for the WG adoption of these documents. Please s= end also simple "yes" or "+1" statements to the list, since we want to also= see how many active participants we currently have. If you have issues abo= ut why the current drafts should not be adopted, please raise them ASAP.=20 The other question is about the editors/co-authors of the WG documents. By = default we will continue with the same list of co-authors as in the individ= ual documents. So, we would like all the current co-authors to send a note = to the chairs whether they are willing to continue (and let us know about y= our realistic time commitment too). One change has already been agreed: sip= -xmpp-media draft will be taken over by Saul Ibarra Corretge and Emil Ivov.= In case someone else is willing to volunteers as a co-chair for one or mor= e of the drafts, let the chairs know. The 'sip-xmpp-media' draft (or the to-be RFC) will still also need a decisi= on about its scope. We'll send a separate mail on that. Regards, Markus & Yana From Markus.Isomaki@nokia.com Wed Jun 19 04:01:41 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85ADF21F9360 for ; Wed, 19 Jun 2013 04:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003] 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 6KdBpjXlW+dy for ; Wed, 19 Jun 2013 04:01:34 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5664821F85C9 for ; Wed, 19 Jun 2013 04:01:33 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5JB1UZ9030104 for ; Wed, 19 Jun 2013 14:01:32 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Jun 2013 14:01:31 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.114]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0328.011; Wed, 19 Jun 2013 11:03:09 +0000 From: To: Thread-Topic: Maturity of the documents Thread-Index: Ac5s2Hq2yqKIskloRiCy6sHWfz6XuQ== Date: Wed, 19 Jun 2013 11:01:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: aZMi/WbTZrlATXhBcdW5gWOAIdeOAxvgmY94Z6VMZnFQSLTjHi7v38UOHXN1e7BWlhZXY49uXZnPbehuWM0KQgxxBOV5fqdeYwUyzAorVYPazgvjiDu9h/ToTpDVSVDY1lrIjrar4wWG5bhqjUn//1ASHQXVTCS4LisgXZN3yAGYeOzf3t3BaCd2BKvYLl0BXvTPfljU1be+Nro+LST2aA7HBhIXxsAGDgdyvwvzPek= x-originating-ip: [172.21.80.71] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620A01C7FC008AM1MPN1042mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2013 11:01:31.0126 (UTC) FILETIME=[5ABCF160:01CE6CDC] X-Nokia-AV: Clean Subject: [Stox] Maturity of the documents X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 11:01:42 -0000 --_000_E44893DD4E290745BB608EB23FDDB7620A01C7FC008AM1MPN1042mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The chairs have started a consensus call on adopting the 'draft-saintandre-= sip-xmpp-' documents as WG items. Please send your feedback on it by replyi= ng to the separate mail about the topic. Somewhat independently of the WG adoption, here is my current understanding= of the maturity of these documents (as a co-chair). This is based on my ow= n reading as well as discussion with some of the co-authors. These documents seem to be in a good shape and will mainly just need review= s: saintandre-sip-xmpp-core saintandre-sip-xmpp-presence saintandre-sip-xmpp-im saintandre-sip-xmpp-chat This document still has open issues. The co-authors are already working on = an update, but further work will still be needed: saintandre-sip-xmpp-groupchat This document requires most work still. It is in my understanding the most = complex piece of these mappings: saintandre-sip-xmpp-media This is just a very informal categorization and people are of course welcom= e to raise any issues or send improvement suggestions with any of these doc= uments still even if we adopt them as WG documents. Markus --_000_E44893DD4E290745BB608EB23FDDB7620A01C7FC008AM1MPN1042mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The chairs have started a consensus call on adopting= the ‘draft-saintandre-sip-xmpp-’ documents as WG items. Please= send your feedback on it by replying to the separate mail about the topic.=

 

Somewhat independently of the WG adoption, here is m= y current understanding of the maturity of these documents (as a co-chair).= This is based on my own reading as well as discussion with some of the co-= authors.

 

These documents seem to be in a good shape and wi= ll mainly just need reviews:

 

saintandre-sip-xmpp-core

saintandre-sip-xmpp-presence

saintandre-sip-xmpp-im

saintandre-sip-xmpp-chat

 

This document still has open issues. The co-autho= rs are already working on an update, but further work will still be needed:=

 

saintandre-sip-xmpp-groupchat

 

This document requires most work still. It is in = my understanding the most complex piece of these mappings:

 

saintandre-sip-xmpp-media

 

This is just a very informal categorization and peop= le are of course welcome to raise any issues or send improvement suggestion= s with any of these documents still even if we adopt them as WG documents.<= o:p>

 

Markus

 

--_000_E44893DD4E290745BB608EB23FDDB7620A01C7FC008AM1MPN1042mg_-- From yana@sip-communicator.org Wed Jun 19 04:04:42 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4C621F9BF0 for ; Wed, 19 Jun 2013 04:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 VMl+e333Dkhz for ; Wed, 19 Jun 2013 04:04:41 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4A20E21F9BC9 for ; Wed, 19 Jun 2013 04:04:41 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so4319897wes.4 for ; Wed, 19 Jun 2013 04:04:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=uqE09mLY6VFoGWJEX8Uu/4Dheh72tCtRe5p/mG3se/k=; b=csqIItE5nsx0kQa+atkCxiBl6eL0tGfy2M3Xk+zWTwTUHjVJbs3pKWSpPwrbLBVOcm PMWsKimbHQ6cWuqqaPsJZE+LIG8tQeQs6k2ADgKfwLlYsFr/1ojYrkRnEhGHFG4LBId4 4ocqFAKg7r+rxoyoo3n1DsLwUg99nuR9ZTpdoH4M907tS0zO0ZIYzPXwxJ30O+g0IlEp qHr93X3++hAQ5iUAykIrfH2WUj9ysvHku298kYb5XYrtDRyWMESwfiJfTo/yDuk8dRig bgiS8iM6ShAx8bWTsfVCBLzb6gRgrsYxcw91IjwavAbHcUAU1iQ1cNnxp7SRi/440iI8 iZCQ== X-Received: by 10.180.183.40 with SMTP id ej8mr1659035wic.37.1371639880406; Wed, 19 Jun 2013 04:04:40 -0700 (PDT) Received: from [192.168.1.31] (lec67-2-82-226-207-96.fbx.proxad.net. [82.226.207.96]) by mx.google.com with ESMTPSA id fo10sm8406364wib.8.2013.06.19.04.04.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 04:04:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Yana Stamcheva In-Reply-To: Date: Wed, 19 Jun 2013 13:04:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: stox@ietf.org X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQkvkJ/0Sw5wv1Ns/QcX0wBbydKIkxpa+EKwiMBPRMJ4OeJhdotGokrpj0fFytwpbZP1iyCx Subject: Re: [Stox] STOX WG officially approved - charter and work plan X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 11:04:42 -0000 The wiki is now also updated and you can find all related information = regrouped here: http://trac.tools.ietf.org/wg/stox/trac/wiki. Yana On Jun 19, 2013, at 11:57 AM, Markus.Isomaki@nokia.com wrote: > Hi all, >=20 > The SIP-to-XMPP (STOX) WG has now been officially approved by the = IESG. Our charter can be found at = . Myself = (markus.isomaki@nokia.com) and Yana Stamcheva (yana@jitsi.org) will act = as co-chairs.=20 >=20 > The plan outlined in the charter is that this will be a focused and = relatively straight-forward effort that we aim to finish in just a few = months. The charter has these milestones: >=20 > Jun 2013 Accept starting-point mapping specifications as WG items > Aug 2013 Start Working Group Last Call on mapping specifications > Oct 2013 Submit mapping specifications to the IESG >=20 > Yana and I have additionally outlined a bit more detailed plan: >=20 > - June: One week consensus call on adopting the current drafts as WG = items. > - Latest by July 8: Submit current drafts as -00 WG drafts. > - July: Ask people to comment and raise open issues about the drafts, = ask co-authors to prepare presentations about open issues for IETF 87. = Start recruiting reviewers and if needed, co-authors.=20 > - IETF 87: Meet for 1 hour. Discuss open issues. Agree on the = deadline for reviews and WG last call on the documents. Decide if all = documents can proceed in the same timeline, or whether some phasing will = be needed.=20 > - By end of August: Start the official WG last call.=20 > - September - October: Process last call comments and finalize the = documents for the IESG review.=20 > - IETF 88: Meet if there is interest and energy to discuss about = rechartering, i.e. adding new WG items. >=20 > Let us know if you have any feedback to this. >=20 > I will next send a few mails to the list about specific topics such as = our first milestone, i.e. the acceptance of the current drafts as WG = items. >=20 > Markus=20 >=20 >=20 From Markus.Isomaki@nokia.com Wed Jun 19 04:56:44 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B5D21F9A48 for ; Wed, 19 Jun 2013 04:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.737 X-Spam-Level: X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=0.861, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 10P37jfedxjk for ; Wed, 19 Jun 2013 04:56:39 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3303421F9BAF for ; Wed, 19 Jun 2013 04:56:32 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5JBuPwd029344; Wed, 19 Jun 2013 14:56:26 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jun 2013 14:56:25 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.114]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0328.011; Wed, 19 Jun 2013 11:58:04 +0000 From: To: , , , Thread-Topic: Mapping for media signaling: still about the scope Thread-Index: Ac5s3MA7fW54rEx1RRO+pgL1gkj4zQ== Date: Wed, 19 Jun 2013 11:56:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: aZMi/WbTZrlATXhBcdW5gfsN6L2OVGdoqvZ0YrGGtDRLhoN4xaUWDpMAFW7/tW/3JnWe7JAQ5KzFTEpQfykjBhaZlqdOYI6jzqJj4m2OJvNZmdMclNjn+6NTBQSLqwIYvcr+Ly9ajFkAYUWBhkZLF7fsflQteULPDmkbBZVdpa7eYALdNI5svMtxzLvtf38JOexk8jHRwCId87rTk8aRb3sM/SXaeVyalRxa2IKaVqJm1yIIJdstaQJbplIKA518XgfdwmJcKjgtvCHdQL9J1Q== x-originating-ip: [172.21.80.71] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620A01C877008AM1MPN1042mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2013 11:56:25.0903 (UTC) FILETIME=[069403F0:01CE6CE4] X-Nokia-AV: Clean Subject: [Stox] Mapping for media signaling: still about the scope X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 11:56:44 -0000 --_000_E44893DD4E290745BB608EB23FDDB7620A01C877008AM1MPN1042mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Emil, Saul, Peter, and others, Recently I raised some questions about the scope of the 'sip-xmpp-media' an= d the related deliverable on the 'mapping for media signaling': http://www.= ietf.org/mail-archive/web/stox/current/msg00025.html Now that STOX is officially up and running I'd like us to make an actual pl= an on what the scope of this document should be, i.e. what features are exp= licitly going to be part of this mapping spec. Although people have success= fully implemented SIP-to-XMPP media signaling gateways, I at least see this= topic to have some complexity due to: - SDP offer/answer is a moving target as new features are being ad= ded as we speak, including "bundle" and "trickle-ICE". We can't know about = what features will be added later on. - There are features currently supported in XMPP that are not curr= ently supported in SIP (and perhaps vice versa?), such as the trickle-ICE = support in Jingle. - Regardless of what is supported in each protocol in general, the= actual SIP and XMPP clients will support different sets of features. Ideally, some things might be mapped transparently in the gateway in an "al= gorithmic" manner. And ideally, the clients supporting different feature se= ts can negotiate end-to-end without needing for the gateway to mediate. How= ever, I'm not sure how easy this will be in practice. Actually one reason why I see these complications may be that I don't have = a very good overall understanding about how SDP O/A (as in RFC 3264 syntax = and semantics) is mapped to XMPP/Jingle (as in its XML based syntax) are in= general kept "in synch". For instance, if IETF extends SDP O/A in some way= , will that always require an explicit corresponding extension XEP by the X= SF, or is there some more straightforward "algorithmic" way to convey somet= hing new on the SIP/SDP side to the XMPP/Jingle side. In the earlier discussion the following proposal by Saul got some support: > Could we perhaps have sip-xmpp-media be the base spec which uses the RFC3= 264 model and later extend it with ICE trickle and friends This also sounds fine to me on the high level. As people have already imple= mented these gateways, writing a document about how they do their work shou= ld be doable. However, we should elaborate this plan a bit beyond the one l= ine of text. Emil, Saul: You have agreed to work as co-authors of this document. Thanks = ;-) Would you be able to write a short proposal about: - What end-to-end media setup features should the mapping spec exp= licitly cover. - What will happen to features supported on one or either side of = the gateway that the gateway is not aware of - can some things be "transpar= ently" mapped or will the gateway become the "blocking factor" in the middl= e. (I.e., will the session setup be limited to the features the gateway exp= licitly needs to "understand".) - How will we extend the mapping spec in the future and how should= the initial spec take this into account. This would be very useful so we can set the expectations about what we can/= should deliver in October, and what is possibly left for the future. Let me= know if this sounds reasonable. Thanks, Markus --_000_E44893DD4E290745BB608EB23FDDB7620A01C877008AM1MPN1042mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Emil, Saul, Peter, and others,

 

Recently I raised some questions about the scope of = the ‘sip-xmpp-media’ and the related deliverable on the ‘= mapping for media signaling’: http://www.ietf.org/mail-archive/web/stox/current/msg00025.html

 

Now that STOX is officially up and running I’d= like us to make an actual plan on what the scope of this document should b= e, i.e. what features are explicitly going to be part of this mapping spec.= Although people have successfully implemented SIP-to-XMPP media signaling gateways, I at least see this topic to have so= me complexity due to:

-     &= nbsp;    SDP offer/answer is a moving target as new features= are being added as we speak, including “bundle” and “tri= ckle-ICE”. We can’t know about what features will be added late= r on.

-     &= nbsp;    There are features currently supported in XMPP that= are not currently  supported in SIP (and perhaps vice versa?), such a= s the trickle-ICE support in Jingle.

-     &= nbsp;    Regardless of what is supported in each protocol in= general, the actual SIP and XMPP clients will support different sets of fe= atures.

 

Ideally, some things might be mapped transparently i= n the gateway in an “algorithmic” manner. And ideally, the clie= nts supporting different feature sets can negotiate end-to-end without need= ing for the gateway to mediate. However, I’m not sure how easy this will be in practice.

 

Actually one reason why I see these complications ma= y be that I don’t have a very good overall understanding about how SD= P O/A (as in RFC 3264 syntax and semantics) is mapped to XMPP/Jingle (as in= its XML based syntax) are in general kept “in synch”. For instance, if IETF extends SDP O/A in some way,= will that always require an explicit corresponding extension XEP by the XS= F, or is there some more straightforward “algorithmic” way to c= onvey something new on the SIP/SDP side to the XMPP/Jingle side.

 

In the earlier discussion the following proposal by = Saul got some support:

 

> Could we perhaps have sip-xmpp-media be the bas= e spec which uses the RFC3264 model and later extend it with ICE trickle an= d friends

 

This also sounds fine to me on the high level. As pe= ople have already implemented these gateways, writing a document about how = they do their work should be doable. However, we should elaborate this plan= a bit beyond the one line of text.

 

Emil, Saul: You have agreed to work as co-authors of= this document. Thanks ;-) Would you be able to write a short proposal abou= t:

-     &= nbsp;    What end-to-end media setup features should the map= ping spec explicitly cover.

-     &= nbsp;    What will happen to features supported on one or ei= ther side of the gateway that the gateway is not aware of – can some = things be “transparently” mapped or will the gateway become the= “blocking factor” in the middle. (I.e., will the session setup be limited to the features the gateway explicitly needs to &= #8220;understand”.)

-     &= nbsp;    How will we extend the mapping spec in the future a= nd how should the initial spec take this into account.

 

This would be very useful so we can set the expectat= ions about what we can/should deliver in October, and what is possibly left= for the future. Let me know if this sounds reasonable.

 

Thanks,

        &nbs= p;       Markus

--_000_E44893DD4E290745BB608EB23FDDB7620A01C877008AM1MPN1042mg_-- From mary.ietf.barnes@gmail.com Wed Jun 19 07:28:04 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DDD21F9C2F for ; Wed, 19 Jun 2013 07:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.065 X-Spam-Level: X-Spam-Status: No, score=-102.065 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87, 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 Ok0IDa8Jh3bX for ; Wed, 19 Jun 2013 07:28:03 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 77A1821F9C1E for ; Wed, 19 Jun 2013 07:28:03 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s1so3124633qcw.1 for ; Wed, 19 Jun 2013 07:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kR3qPCGtGCMK0SyhrS4OKAUQulZ2fm3UKmch3DjvJYI=; b=uqx8r+AJ8WQeG+ivE77mwQuyyhpFv74PjKQJ9sf6nYO6WjMaTmrvra1Y9EaA1r/ksW KArwfW+nbSwZG5lt5SSvDu9e6JKzP+B3tf60fVy5OdeQ724TGYxtpTsaFnWbl0hfZ3iu 1fvVSashya2Dpu3Gk4zPfEQKQOoKM2FLPQ7vyeKh1/WCWAAXhe8g+G5vZN0gRYdScBdz ZE6hvr47euQ+tdsSGaIAZMFTdN+If3HiGqg0nQ1mmifNdKoPeaNwg6DdFOelj3pL+nHc tcrJw7QOd34D9J2NsfMmbzSPMyEuiWeMoOTa3/ubIFdqqjCz40cdTx4NaAA42tuGz8e2 je6Q== MIME-Version: 1.0 X-Received: by 10.224.168.14 with SMTP id s14mr3969613qay.91.1371652082512; Wed, 19 Jun 2013 07:28:02 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 19 Jun 2013 07:28:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Jun 2013 09:28:02 -0500 Message-ID: From: Mary Barnes To: "markus.isomaki@nokia.com" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: stox@ietf.org Subject: Re: [Stox] Maturity of the documents X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:28:04 -0000 I fully support this proposal. Although, there were concerns raised during chartering that it seemed that the WG would just fell swoop adopt this documents - I personally feel that enough time has elapsed for someone to do that if they had the intention. But, it might be good to set a deadline on this proposal for adopting these as WG documents and make that the same deadline for anyone with alternative proposals towards the milestones. Regards, Mary. On Wed, Jun 19, 2013 at 6:01 AM, wrote: > Hi, > > > > The chairs have started a consensus call on adopting the > =91draft-saintandre-sip-xmpp-=92 documents as WG items. Please send your > feedback on it by replying to the separate mail about the topic. > > > > Somewhat independently of the WG adoption, here is my current understandi= ng > of the maturity of these documents (as a co-chair). This is based on my o= wn > reading as well as discussion with some of the co-authors. > > > > These documents seem to be in a good shape and will mainly just need > reviews: > > > > saintandre-sip-xmpp-core > > saintandre-sip-xmpp-presence > > saintandre-sip-xmpp-im > > saintandre-sip-xmpp-chat > > > > This document still has open issues. The co-authors are already working o= n > an update, but further work will still be needed: > > > > saintandre-sip-xmpp-groupchat > > > > This document requires most work still. It is in my understanding the mos= t > complex piece of these mappings: > > > > saintandre-sip-xmpp-media > > > > This is just a very informal categorization and people are of course welc= ome > to raise any issues or send improvement suggestions with any of these > documents still even if we adopt them as WG documents. > > > > Markus > > > > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > From mary.ietf.barnes@gmail.com Wed Jun 19 07:31:23 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EE721F9ABA for ; Wed, 19 Jun 2013 07:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.889 X-Spam-Level: X-Spam-Status: No, score=-102.889 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87, 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 iLiAAq91VjnZ for ; Wed, 19 Jun 2013 07:31:19 -0700 (PDT) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 878DC21F9976 for ; Wed, 19 Jun 2013 07:31:08 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so3304768qee.12 for ; Wed, 19 Jun 2013 07:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AKg4AqX/VGQFHdmXsY5gnr5ZbZeHcAIZOjj0t7Yntxs=; b=wsuxXBgb0uRpqstAFR9eycZ8OXvHnMow3n4WAsMcG9ttnMIKxB7C5hJp4n6S2FAQVQ rjthZ9t0t3E5e2gdGe08eGhZf/13j8VrKC97JSffeVr2E91h5Wy3qr5iOi+zKVNOvpXv pR3kMK0MGMvI9aUZMfjvryxxu6OuelNsxX5Ed9HlR4h/akTRr98JfSUSaiO/Z4HZ5O3k WpbGRAzdlHnKrEIY3vM1xrwKfFFxM8vYIvlQdWLpt5upM9eTwcvhWSE/784nVnLg2UqI xk6VgGoNjF331nKAQM5+mavlI3Sb6jjkrHAG5ea5/KiKP9T5DVvEUBXEV9nlimmLZnIb CBwQ== MIME-Version: 1.0 X-Received: by 10.224.180.133 with SMTP id bu5mr4067695qab.50.1371652267814; Wed, 19 Jun 2013 07:31:07 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Wed, 19 Jun 2013 07:31:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Jun 2013 09:31:07 -0500 Message-ID: From: Mary Barnes To: "markus.isomaki@nokia.com" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: stox@ietf.org Subject: Re: [Stox] Maturity of the documents X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:31:23 -0000 Sorry - I should have read all the emails as I see the deadline in this ema= il: http://www.ietf.org/mail-archive/web/stox/current/msg00058.html So, maybe just be explicit that this is the deadline for any alternative proposals. Thanks, Mary. On Wed, Jun 19, 2013 at 9:28 AM, Mary Barnes w= rote: > I fully support this proposal. Although, there were concerns raised > during chartering that it seemed that the WG would just fell swoop > adopt this documents - I personally feel that enough time has elapsed > for someone to do that if they had the intention. But, it might be > good to set a deadline on this proposal for adopting these as WG > documents and make that the same deadline for anyone with alternative > proposals towards the milestones. > > Regards, > Mary. > > On Wed, Jun 19, 2013 at 6:01 AM, wrote: >> Hi, >> >> >> >> The chairs have started a consensus call on adopting the >> =91draft-saintandre-sip-xmpp-=92 documents as WG items. Please send your >> feedback on it by replying to the separate mail about the topic. >> >> >> >> Somewhat independently of the WG adoption, here is my current understand= ing >> of the maturity of these documents (as a co-chair). This is based on my = own >> reading as well as discussion with some of the co-authors. >> >> >> >> These documents seem to be in a good shape and will mainly just need >> reviews: >> >> >> >> saintandre-sip-xmpp-core >> >> saintandre-sip-xmpp-presence >> >> saintandre-sip-xmpp-im >> >> saintandre-sip-xmpp-chat >> >> >> >> This document still has open issues. The co-authors are already working = on >> an update, but further work will still be needed: >> >> >> >> saintandre-sip-xmpp-groupchat >> >> >> >> This document requires most work still. It is in my understanding the mo= st >> complex piece of these mappings: >> >> >> >> saintandre-sip-xmpp-media >> >> >> >> This is just a very informal categorization and people are of course wel= come >> to raise any issues or send improvement suggestions with any of these >> documents still even if we adopt them as WG documents. >> >> >> >> Markus >> >> >> >> >> _______________________________________________ >> stox mailing list >> stox@ietf.org >> https://www.ietf.org/mailman/listinfo/stox >> From stpeter@stpeter.im Wed Jun 19 10:09:15 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E584121F9E04 for ; Wed, 19 Jun 2013 10:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.138 X-Spam-Level: X-Spam-Status: No, score=-102.138 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 SEUVMtK+HxIL for ; Wed, 19 Jun 2013 10:09:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B4FC421F9E06 for ; Wed, 19 Jun 2013 10:09:02 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E72A541278; Wed, 19 Jun 2013 11:09:02 -0600 (MDT) Message-ID: <51C1E5AC.6070105@stpeter.im> Date: Wed, 19 Jun 2013 11:09:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yana Stamcheva References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stox@ietf.org Subject: Re: [Stox] STOX WG officially approved - charter and work plan X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:09:16 -0000 Thanks for the detailed plan and information. I'm looking forward to working with you all on getting this done. :-) On 6/19/13 5:04 AM, Yana Stamcheva wrote: > The wiki is now also updated and you can find all related information regrouped here: http://trac.tools.ietf.org/wg/stox/trac/wiki. > > Yana > > On Jun 19, 2013, at 11:57 AM, Markus.Isomaki@nokia.com wrote: > >> Hi all, >> >> The SIP-to-XMPP (STOX) WG has now been officially approved by the IESG. Our charter can be found at . Myself (markus.isomaki@nokia.com) and Yana Stamcheva (yana@jitsi.org) will act as co-chairs. >> >> The plan outlined in the charter is that this will be a focused and relatively straight-forward effort that we aim to finish in just a few months. The charter has these milestones: >> >> Jun 2013 Accept starting-point mapping specifications as WG items >> Aug 2013 Start Working Group Last Call on mapping specifications >> Oct 2013 Submit mapping specifications to the IESG >> >> Yana and I have additionally outlined a bit more detailed plan: >> >> - June: One week consensus call on adopting the current drafts as WG items. >> - Latest by July 8: Submit current drafts as -00 WG drafts. >> - July: Ask people to comment and raise open issues about the drafts, ask co-authors to prepare presentations about open issues for IETF 87. Start recruiting reviewers and if needed, co-authors. >> - IETF 87: Meet for 1 hour. Discuss open issues. Agree on the deadline for reviews and WG last call on the documents. Decide if all documents can proceed in the same timeline, or whether some phasing will be needed. >> - By end of August: Start the official WG last call. >> - September - October: Process last call comments and finalize the documents for the IESG review. >> - IETF 88: Meet if there is interest and energy to discuss about rechartering, i.e. adding new WG items. >> >> Let us know if you have any feedback to this. >> >> I will next send a few mails to the list about specific topics such as our first milestone, i.e. the acceptance of the current drafts as WG items. >> >> Markus >> >> > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox > From saul@ag-projects.com Wed Jun 19 10:10:30 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A499421F9E34 for ; Wed, 19 Jun 2013 10:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] 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 PXIAc-VC2hLK for ; Wed, 19 Jun 2013 10:10:26 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id BDDD821F9E28 for ; Wed, 19 Jun 2013 10:10:25 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 29A52B35E1; Wed, 19 Jun 2013 19:10:25 +0200 (CEST) Received: from [192.168.99.48] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id EE67EB017A; Wed, 19 Jun 2013 19:10:23 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <51C1E5AC.6070105@stpeter.im> Date: Wed, 19 Jun 2013 19:10:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C1E5AC.6070105@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: stox@ietf.org, Yana Stamcheva Subject: Re: [Stox] STOX WG officially approved - charter and work plan X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:10:30 -0000 Likewise! On Jun 19, 2013, at 7:09 PM, Peter Saint-Andre = wrote: > Thanks for the detailed plan and information. I'm looking forward to > working with you all on getting this done. :-) >=20 > On 6/19/13 5:04 AM, Yana Stamcheva wrote: >> The wiki is now also updated and you can find all related information = regrouped here: http://trac.tools.ietf.org/wg/stox/trac/wiki. >>=20 >> Yana >>=20 >> On Jun 19, 2013, at 11:57 AM, Markus.Isomaki@nokia.com wrote: >>=20 >>> Hi all, >>>=20 >>> The SIP-to-XMPP (STOX) WG has now been officially approved by the = IESG. Our charter can be found at = . Myself = (markus.isomaki@nokia.com) and Yana Stamcheva (yana@jitsi.org) will act = as co-chairs.=20 >>>=20 >>> The plan outlined in the charter is that this will be a focused and = relatively straight-forward effort that we aim to finish in just a few = months. The charter has these milestones: >>>=20 >>> Jun 2013 Accept starting-point mapping specifications as WG items >>> Aug 2013 Start Working Group Last Call on mapping specifications >>> Oct 2013 Submit mapping specifications to the IESG >>>=20 >>> Yana and I have additionally outlined a bit more detailed plan: >>>=20 >>> - June: One week consensus call on adopting the current drafts as WG = items. >>> - Latest by July 8: Submit current drafts as -00 WG drafts. >>> - July: Ask people to comment and raise open issues about the = drafts, ask co-authors to prepare presentations about open issues for = IETF 87. Start recruiting reviewers and if needed, co-authors.=20 >>> - IETF 87: Meet for 1 hour. Discuss open issues. Agree on the = deadline for reviews and WG last call on the documents. Decide if all = documents can proceed in the same timeline, or whether some phasing will = be needed.=20 >>> - By end of August: Start the official WG last call.=20 >>> - September - October: Process last call comments and finalize the = documents for the IESG review.=20 >>> - IETF 88: Meet if there is interest and energy to discuss about = rechartering, i.e. adding new WG items. >>>=20 >>> Let us know if you have any feedback to this. >>>=20 >>> I will next send a few mails to the list about specific topics such = as our first milestone, i.e. the acceptance of the current drafts as WG = items. >>>=20 >>> Markus=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> stox mailing list >> stox@ietf.org >> https://www.ietf.org/mailman/listinfo/stox >>=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox -- Sa=FAl Ibarra Corretg=E9 AG Projects From stpeter@stpeter.im Wed Jun 19 10:24:38 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D5621F9E50 for ; Wed, 19 Jun 2013 10:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.115 X-Spam-Level: X-Spam-Status: No, score=-102.115 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 G1Y0Dtkj2LzG for ; Wed, 19 Jun 2013 10:24:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B9BB921F9E52 for ; Wed, 19 Jun 2013 10:24:32 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0483241278; Wed, 19 Jun 2013 11:24:31 -0600 (MDT) Message-ID: <51C1E94D.4050204@stpeter.im> Date: Wed, 19 Jun 2013 11:24:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: stox@ietf.org Subject: Re: [Stox] Maturity of the documents X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 17:24:38 -0000 On 6/19/13 5:01 AM, Markus.Isomaki@nokia.com wrote: > This document still has open issues. The co-authors are already working > on an update, but further work will still be needed: > > saintandre-sip-xmpp-groupchat Saúl, Salvatore, and I plan to submit a revised I-D for the groupchat document by the end of this week. > This document requires most work still. It is in my understanding the > most complex piece of these mappings: > > saintandre-sip-xmpp-media Yes, we need to have more discussion about that one. There is a great deal of flux happening in this space right now (e.g., WebRTC using raw SDP -- or not, as being discussed right now in the RTCWEB WG). Peter -- Peter Saint-Andre https://stpeter.im/ From emil@sip-communicator.org Wed Jun 19 11:00:17 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3388A21F9DD1 for ; Wed, 19 Jun 2013 11:00:17 -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 FWdDs-v4GYjY for ; Wed, 19 Jun 2013 11:00:16 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D85BB21F9DCF for ; Wed, 19 Jun 2013 11:00:15 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so994556wiv.2 for ; Wed, 19 Jun 2013 11:00:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=hXFNMO/nCHjCdwsQb8o2BKjHp/1j+T6/LT6bVG08nTw=; b=nWOdPW9wxH1pIYWaCVV3UThPYji9d/peN/dSn87iffbaX3Ag3H3zy2f6NS0jtkbthA 06BN4eDe1PJNMa9xsxmKon06qJApRJwQ/1d8QM3eP17fI6DYx/Uh2wmJ/HNvzgyxw+u1 YmRqV1kKG1yftk2QZtXCHXG7RvLSVNYj0gtakuYp0AyF4TGoHkYbrVuvwfR7A0zhlt61 JioblU9I/O38/B45QUOWZYzCV3Q7WXHyxK61NMQ0Lz5jf9A/vwWEBc4lXoZYSBDaoP/m PRefWr8lLypacF6KsjN0L3ng62pXYeOgF97+sRQmTMWpsIKISEwBNT+nBKI7JU7Ujflx MDlA== X-Received: by 10.194.63.229 with SMTP id j5mr3044922wjs.79.1371664814880; Wed, 19 Jun 2013 11:00:14 -0700 (PDT) Received: from camionet.local ([2a01:e35:2e2c:f600:a929:df1f:bef6:68ec]) by mx.google.com with ESMTPSA id b11sm10818462wiv.10.2013.06.19.11.00.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 11:00:14 -0700 (PDT) Message-ID: <51C1F1AB.1040701@jitsi.org> Date: Wed, 19 Jun 2013 20:00:11 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkMuw5jYysOFbauMRwyQmlGDV6xPLFivc7F830lGpVlbIXzHFT17xcXERNiRQlEUgZFXsfu Cc: stox@ietf.org, saul@ag-projects.com, stpeter@stpeter.im Subject: Re: [Stox] Mapping for media signaling: still about the scope X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:00:17 -0000 Hey Markus On 19.06.13, 13:56, Markus.Isomaki@nokia.com wrote: > Hi Emil, Saul, Peter, and others, > > Recently I raised some questions about the scope of the =91sip-xmpp-med= ia=92 > and the related deliverable on the =91mapping for media signaling=92: > http://www.ietf.org/mail-archive/web/stox/current/msg00025.html > > Now that STOX is officially up and running I=92d like us to make an act= ual > plan on what the scope of this document should be, i.e. what features > are explicitly going to be part of this mapping spec. Although people > have successfully implemented SIP-to-XMPP media signaling gateways, I a= t > least see this topic to have some complexity due to: > > -SDP offer/answer is a moving target as new features are being added as= > we speak, Well ... it is and it isn't. 3264 isn't really changing and all=20 extensions are supposed to keep backward compatibility with it. > including =93bundle=94 and =93trickle-ICE=94. We can=92t know about wha= t > features will be added later on. No, but we could include some that we know of ... like "bundle" and=20 "trickle-ICE" :). Trickle ICE would be easier because we already have it in Jingle and the = SIP version shouldn't take long. > -There are features currently supported in XMPP that are not currently > supported in SIP (and perhaps vice versa?), such as the trickle-ICE > support in Jingle. As mentioned. I don't think trickle-ICE would be a problem. I believe=20 separating transport and encoding information would be a bigger hurdle=20 but if we accept that urn:ietf:rfc:3264 means one shouldn't do this. > -Regardless of what is supported in each protocol in general, the actua= l > SIP and XMPP clients will support different sets of features. Right. > Ideally, some things might be mapped transparently in the gateway in an= > =93algorithmic=94 manner. I don't believe this would be possible. > And ideally, the clients supporting different > feature sets can negotiate end-to-end without needing for the gateway t= o > mediate. However, I=92m not sure how easy this will be in practice. > > Actually one reason why I see these complications may be that I don=92t= > have a very good overall understanding about how SDP O/A (as in RFC 326= 4 > syntax and semantics) is mapped to XMPP/Jingle (as in its XML based > syntax) are in general kept =93in synch=94. For instance, if IETF exten= ds > SDP O/A in some way, will that always require an explicit corresponding= > extension XEP by the XSF, or is there some more straightforward > =93algorithmic=94 way to convey something new on the SIP/SDP side to th= e > XMPP/Jingle side. Well, the good thing about O/A extensions is that they generally=20 preserve backward compatibility. This is valid for things like ICE,=20 trickle ICE, rtcp-mux, bundle. So as long as we support 3264 we should=20 be OK. I think :) > In the earlier discussion the following proposal by Saul got some suppo= rt: > > > Could we perhaps have sip-xmpp-media be the base spec which uses the= > RFC3264 model and later extend it with ICE trickle and friends > > This also sounds fine to me on the high level. As people have already > implemented these gateways, writing a document about how they do their > work should be doable. However, we should elaborate this plan a bit > beyond the one line of text. > > Emil, Saul: You have agreed to work as co-authors of this document. > Thanks ;-) Would you be able to write a short proposal about: Sure! > -What end-to-end media setup features should the mapping spec explicitl= y > cover. OK, so how about starting with 3261, 3264, 4585, 5285, 5761. I think we can also add trickle ICE since I don't believe we have much=20 work left for SIP. Personally I wouldn't even mind having BUNDLE, we'd just need to have=20 the feature in Jingle. > -What will happen to features supported on one or either side of the > gateway that the gateway is not aware of=96 can some things be > =93transparently=94 mapped or will the gateway become the =93blocking f= actor=94 > in the middle. (I.e., will the session setup be limited to the features= > the gateway explicitly needs to =93understand=94.) I don't think the gateway could just forward anything because this would = imply a straightforward mapping from any SDP attribute to a Jingle elemen= t. Maybe gateways could behave as regular SIP B2BUAs: they forward the=20 things that they understand and they remove those that they don't=20 understand or support. Thoughts? > -How will we extend the mapping spec in the future and how should the > initial spec take this into account. As in administratively? Emil > This would be very useful so we can set the expectations about what we > can/should deliver in October, and what is possibly left for the future= =2E > Let me know if this sounds reasonable. > > Thanks, > > Markus > --=20 https://jitsi.org From fippo@goodadvice.pages.de Wed Jun 19 11:16:14 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E8F21F9B16 for ; Wed, 19 Jun 2013 11:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.729 X-Spam-Level: X-Spam-Status: No, score=-0.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_36=1, SARE_MLH_Stock1=0.87] 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 A9WxemQEasKJ for ; Wed, 19 Jun 2013 11:16:01 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 3875C21F9B12 for ; Wed, 19 Jun 2013 11:16:01 -0700 (PDT) Received: from [192.168.2.100] (p54970053.dip0.t-ipconnect.de [84.151.0.83]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r5JIFwK4031855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Jun 2013 20:15:59 +0200 Message-ID: <51C1F556.2020800@goodadvice.pages.de> Date: Wed, 19 Jun 2013 20:15:50 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stox@ietf.org References: <51C1F1AB.1040701@jitsi.org> In-Reply-To: <51C1F1AB.1040701@jitsi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Stox] Mapping for media signaling: still about the scope X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:16:14 -0000 Am 19.06.2013 20:00, schrieb Emil Ivov: [...] > OK, so how about starting with 3261, 3264, 4585, 5285, 5761. That is the core i'm using in my sdp<->jingle mapping for webrtc purposes. Add 4568 (sdes, a=crypto), 5763 (a=fingerprint for dtls-srtp) and possibly 5576 (a=ssrc) to that list. > I think we can also add trickle ICE since I don't believe we have much > work left for SIP. > > Personally I wouldn't even mind having BUNDLE, we'd just need to have > the feature in Jingle. You can exploit the same-icepwd/ufrag property from http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-04#section-8.1 -- I haven't checked for backward compability issues though. That way it seems we'd only need to have a disco feature for it along with a paragraph in XEP-0176. cheers philipp From stpeter@stpeter.im Wed Jun 19 15:35:44 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046B221F9F3F for ; Wed, 19 Jun 2013 15:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 sgitvsy5EDqx for ; Wed, 19 Jun 2013 15:35:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 839F821F9F3E for ; Wed, 19 Jun 2013 15:35:39 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 50A14410F9; Wed, 19 Jun 2013 16:35:37 -0600 (MDT) Message-ID: <51C23237.30203@stpeter.im> Date: Wed, 19 Jun 2013 16:35:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "stox@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [Stox] core: connecting to remote domain X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 22:35:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While working on the sip-xmpp-groupchat spec today, Saúl and I found what I think is an open issue wiht the sip-xmpp-core spec: it doesn't say how you determine whether a remote domain supports SIP or XMPP (or both). This is needed for interdomain routing of messages. Thus I think the sip-xmpp-core spec needs to contain something like the text in Section 11.2 of RFC 3921: ### 11.2. Outbound Stanzas If the hostname of the domain identifier portion of the address contained in the 'to' attribute of an outbound stanza matches a hostname of the server itself, the server MUST deliver the stanza to a local entity according the rules for Inbound Stanzas (Section 11.1). If the hostname of the domain identifier portion of the address contained in the 'to' attribute of an outbound stanza does not match a hostname of the server itself, the server MUST attempt to route the stanza to the foreign domain. The recommended order of actions is as follows: 1. First attempt to resolve the foreign hostname using an [SRV] Service of "xmpp-server" and Proto of "tcp", resulting in resource records such as "_xmpp-server._tcp.example.com.", as specified in [XMPP-CORE]. 2. If the "xmpp-server" address record resolution fails, attempt to resolve the "_im" or "_pres" [SRV] Service as specified in [IMP-SRV], using the "_im" Service for stanzas and the "_pres" Service for stanzas (it is up to the implementation how to handle stanzas). This will result in one or more resolutions of the form "_im..example.com." or "_pres..example.com.", where "" would be a label registered in the Instant Messaging SRV Protocol Label registry or the Presence SRV Protocol Label registry: either "_xmpp" for an XMPP-aware domain or some other IANA-registered label (e.g., "_simple") for a non-XMPP-aware domain. 3. If both SRV address record resolutions fail, attempt to perform a normal IPv4/IPv6 address record resolution to determine the IP address using the "xmpp-server" port of 5269 registered with the IANA, as specified in [XMPP-CORE]. Administrators of server deployments are strongly encouraged to keep the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records properly synchronized, since different implementations might perform the "_im" and "_pres" lookups before the "xmpp-server" lookup. ### However, we'd need text describing the discovery and decision process in both directions (and IMHO we need to drop the _im and _pres SRV stuff, as we did when working on RFC 6121). Thoughts? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwjI3AAoJEOoGpJErxa2pL48QAIMtAOVzfirffe9yZotJ3NCi 9Y+vVAAr2dk9I0f9WOVPFLjP0ylESObRzq6GUyJ2k0iYycTWEyRgz4pBXN8XDgtJ cjMI7A4zLtYHEvuXXEOSgRQi8L27CpHAZGuBoZLhTyZ1GcPuGNt/NDJIQntP7tRr KD8grRTMg9Sxel0HaEeMJmggyYIvs85mdoZZBHuGrCSwgaYuy+JfdhgfCJCIxMNc RbVDfL4xEg0Mgx5seJ/sfojjJ7NT6yXk1SBNXGcj3eCTy5vwn1TvVDUi025/DEcM lX6lOlOLi2c+FWkVr2qXfRNntyDFTPbYTSDX/r8jnHvfKd06ciaM0NHai6QN7nUp nbvE+Zyv2lTgTkyJMsM16JBKGJfhBdtKIuhi5KRvbqRlcvNz1RLbDOBAV7whS/xO XcouS+TA3Txwb5tMRUSQ6AJYiN0i1cWwGCRcFufZBk0fCbo1qzEf56D6lF45QRCJ TTRGTIJaE6mNtVTd08gUYcUVfcTh5fkIbs+ZQd5hfwvPfWycpEA/05GoKPWSgY/8 E5nzFdAGtBu/ivUOxtAZLakqhwgOlCyK+p2qE2LXBmgXVLHf9PUm+RIod78PN9/K y1/q6DDe+rMQ339zWkznh8lUR0ibtmXqIsjmEa1Tcisn7CFzqYQ7vI58zG3Xpc4h lhwqWW3Oc5olL74eU8g3 =uhYH -----END PGP SIGNATURE----- From saul@ag-projects.com Wed Jun 19 23:23:05 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAAB11E80D9 for ; Wed, 19 Jun 2013 23:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] 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 NF4vmT1j8dre for ; Wed, 19 Jun 2013 23:22:59 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDE211E8106 for ; Wed, 19 Jun 2013 23:22:53 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 8B557B35DC; Thu, 20 Jun 2013 08:22:52 +0200 (CEST) Received: from [192.168.99.48] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 87E44B017A; Thu, 20 Jun 2013 08:22:51 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <51C23237.30203@stpeter.im> Date: Thu, 20 Jun 2013 08:22:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> References: <51C23237.30203@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "stox@ietf.org" Subject: Re: [Stox] core: connecting to remote domain X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 06:23:05 -0000 Hi! On Jun 20, 2013, at 12:35 AM, Peter Saint-Andre = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > While working on the sip-xmpp-groupchat spec today, Sa=FAl and I found > what I think is an open issue wiht the sip-xmpp-core spec: it doesn't > say how you determine whether a remote domain supports SIP or XMPP (or > both). This is needed for interdomain routing of messages. Thus I > think the sip-xmpp-core spec needs to contain something like the text > in Section 11.2 of RFC 3921: >=20 > ### >=20 > 11.2. Outbound Stanzas >=20 >=20 > If the hostname of the domain identifier portion of the address > contained in the 'to' attribute of an outbound stanza matches a > hostname of the server itself, the server MUST deliver the stanza to > a local entity according the rules for Inbound Stanzas (Section > 11.1). >=20 > If the hostname of the domain identifier portion of the address > contained in the 'to' attribute of an outbound stanza does not match > a hostname of the server itself, the server MUST attempt to route = the > stanza to the foreign domain. The recommended order of actions is = as > follows: >=20 > 1. First attempt to resolve the foreign hostname using an [SRV] > Service of "xmpp-server" and Proto of "tcp", resulting in > resource records such as "_xmpp-server._tcp.example.com.", as > specified in [XMPP-CORE]. >=20 > 2. If the "xmpp-server" address record resolution fails, attempt to > resolve the "_im" or "_pres" [SRV] Service as specified in > [IMP-SRV], using the "_im" Service for stanzas and = the > "_pres" Service for stanzas (it is up to the > implementation how to handle stanzas). This will result = in > one or more resolutions of the form "_im..example.com." = or > "_pres..example.com.", where "" would be a label > registered in the Instant Messaging SRV Protocol Label registry > or the Presence SRV Protocol Label registry: either "_xmpp" for > an XMPP-aware domain or some other IANA-registered label (e.g., > "_simple") for a non-XMPP-aware domain. >=20 > 3. If both SRV address record resolutions fail, attempt to perform = a > normal IPv4/IPv6 address record resolution to determine the IP > address using the "xmpp-server" port of 5269 registered with the > IANA, as specified in [XMPP-CORE]. >=20 > Administrators of server deployments are strongly encouraged to keep > the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records properly > synchronized, since different implementations might perform the = "_im" > and "_pres" lookups before the "xmpp-server" lookup. >=20 > ### >=20 Well, the problem is that in practice a given domain would have records = for both SIP and XMPP, so which one would we check first? I'm not sure = if we can define an unequivocal mechanism to choose the right target, so = I'm tempted to suggest not to define it for the moment and leave it as a = local policy item. If we come up with a way to do it later on, maybe we = can create a new document updating sip-xmpp core? > However, we'd need text describing the discovery and decision process > in both directions (and IMHO we need to drop the _im and _pres SRV > stuff, as we did when working on RFC 6121). >=20 I have never seen _im and _pres out in the wild, so I'm +1 on removing = the mention to them. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ag@ag-projects.com Wed Jun 19 23:28:56 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F1921E8056 for ; Wed, 19 Jun 2013 23:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] 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 b4DYvh55+O3w for ; Wed, 19 Jun 2013 23:28:51 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC3321E80B2 for ; Wed, 19 Jun 2013 23:28:51 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id EC675B35DC; Thu, 20 Jun 2013 08:28:50 +0200 (CEST) Received: from ag-retina.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id D9E87B017A; Thu, 20 Jun 2013 08:28:49 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Adrian Georgescu In-Reply-To: <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> Date: Thu, 20 Jun 2013 08:28:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C23237.30203@stpeter.im> <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Mailer: Apple Mail (2.1508) Cc: "stox@ietf.org" , Peter Saint-Andre Subject: Re: [Stox] core: connecting to remote domain X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 06:28:56 -0000 XMPP has defined DNS records for both C2S and S2S connections. One = domain may have a server to server XMPP capability but would not accept = client connections (missing correspondent DNS record), this would give = me a clue that that foreign domain has such XMPP 2 SIP gateway in place = and if I am a client of that domain I know I cannot use an XMPP client = for it. For SIP however, is not clear as the same DNS records are used = both by clients and servers to locate the Proxy/Registrar for a given = domain. This is the missing piece that makes a heuristic approach not = 100% accurate.=20 Adrian On Jun 20, 2013, at 8:22 AM, Sa=FAl Ibarra Corretg=E9 = wrote: > Hi! >=20 > On Jun 20, 2013, at 12:35 AM, Peter Saint-Andre = wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> While working on the sip-xmpp-groupchat spec today, Sa=FAl and I = found >> what I think is an open issue wiht the sip-xmpp-core spec: it doesn't >> say how you determine whether a remote domain supports SIP or XMPP = (or >> both). This is needed for interdomain routing of messages. Thus I >> think the sip-xmpp-core spec needs to contain something like the text >> in Section 11.2 of RFC 3921: >>=20 >> ### >>=20 >> 11.2. Outbound Stanzas >>=20 >>=20 >> If the hostname of the domain identifier portion of the address >> contained in the 'to' attribute of an outbound stanza matches a >> hostname of the server itself, the server MUST deliver the stanza to >> a local entity according the rules for Inbound Stanzas (Section >> 11.1). >>=20 >> If the hostname of the domain identifier portion of the address >> contained in the 'to' attribute of an outbound stanza does not match >> a hostname of the server itself, the server MUST attempt to route = the >> stanza to the foreign domain. The recommended order of actions is = as >> follows: >>=20 >> 1. First attempt to resolve the foreign hostname using an [SRV] >> Service of "xmpp-server" and Proto of "tcp", resulting in >> resource records such as "_xmpp-server._tcp.example.com.", as >> specified in [XMPP-CORE]. >>=20 >> 2. If the "xmpp-server" address record resolution fails, attempt to >> resolve the "_im" or "_pres" [SRV] Service as specified in >> [IMP-SRV], using the "_im" Service for stanzas and = the >> "_pres" Service for stanzas (it is up to the >> implementation how to handle stanzas). This will result = in >> one or more resolutions of the form "_im..example.com." = or >> "_pres..example.com.", where "" would be a label >> registered in the Instant Messaging SRV Protocol Label registry >> or the Presence SRV Protocol Label registry: either "_xmpp" for >> an XMPP-aware domain or some other IANA-registered label (e.g., >> "_simple") for a non-XMPP-aware domain. >>=20 >> 3. If both SRV address record resolutions fail, attempt to perform = a >> normal IPv4/IPv6 address record resolution to determine the IP >> address using the "xmpp-server" port of 5269 registered with the >> IANA, as specified in [XMPP-CORE]. >>=20 >> Administrators of server deployments are strongly encouraged to keep >> the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records properly >> synchronized, since different implementations might perform the = "_im" >> and "_pres" lookups before the "xmpp-server" lookup. >>=20 >> ### >>=20 >=20 > Well, the problem is that in practice a given domain would have = records for both SIP and XMPP, so which one would we check first? I'm = not sure if we can define an unequivocal mechanism to choose the right = target, so I'm tempted to suggest not to define it for the moment and = leave it as a local policy item. If we come up with a way to do it later = on, maybe we can create a new document updating sip-xmpp core? >=20 >> However, we'd need text describing the discovery and decision process >> in both directions (and IMHO we need to drop the _im and _pres SRV >> stuff, as we did when working on RFC 6121). >>=20 >=20 > I have never seen _im and _pres out in the wild, so I'm +1 on removing = the mention to them. >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox >=20 From saul@ag-projects.com Wed Jun 19 23:41:02 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4E021F9C4D for ; Wed, 19 Jun 2013 23:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.905 X-Spam-Level: X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] 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 udL6LQSt0WBy for ; Wed, 19 Jun 2013 23:40:57 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6DE21F9BF1 for ; Wed, 19 Jun 2013 23:40:56 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 00E52B35DC; Thu, 20 Jun 2013 08:40:55 +0200 (CEST) Received: from [192.168.99.48] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 28CA0B017A; Thu, 20 Jun 2013 08:40:55 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Thu, 20 Jun 2013 08:40:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B71F03F-6727-4AFA-B8FD-B82AC51EAFEB@ag-projects.com> References: <51C23237.30203@stpeter.im> <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> To: Adrian Georgescu X-Mailer: Apple Mail (2.1508) Cc: "stox@ietf.org" , Peter Saint-Andre Subject: Re: [Stox] core: connecting to remote domain X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 06:41:02 -0000 On Jun 20, 2013, at 8:28 AM, Adrian Georgescu = wrote: > XMPP has defined DNS records for both C2S and S2S connections. One = domain may have a server to server XMPP capability but would not accept = client connections (missing correspondent DNS record), this would give = me a clue that that foreign domain has such XMPP 2 SIP gateway in place = and if I am a client of that domain I know I cannot use an XMPP client = for it. For SIP however, is not clear as the same DNS records are used = both by clients and servers to locate the Proxy/Registrar for a given = domain. This is the missing piece that makes a heuristic approach not = 100% accurate.=20 >=20 The absence of C2S records could give you a hint, but some gateways may = actually implement it thus allowing you to be on both SIP and XMPP at = the same time from the same domain, so you'll still be confronted with = the same problem. Not to mention deployments where SIP and XMPP are = deployed in parallel for the same domain, which I think it's quite = common these days. Earlier this year, at XMPP summit, someone mentioned that S-NAPTR could = be used for this. Looks like it actually would. See = http://tools.ietf.org/html/rfc3958#section-4.3 I have never seen that deployed though. -- Sa=FAl Ibarra Corretg=E9 AG Projects From salvatore.loreto@ericsson.com Thu Jun 20 02:11:21 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D31621F9E58 for ; Thu, 20 Jun 2013 02:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.058 X-Spam-Level: X-Spam-Status: No, score=-105.058 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87, 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 C-M9ghn6j0bh for ; Thu, 20 Jun 2013 02:11:13 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2B21F9B3F for ; Thu, 20 Jun 2013 02:11:11 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-ec-51c2c72a9731 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 68.8E.15700.A27C2C15; Thu, 20 Jun 2013 11:11:07 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 20 Jun 2013 11:11:06 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 70D5711041D for ; Thu, 20 Jun 2013 12:11:06 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E331F55398 for ; Thu, 20 Jun 2013 12:11:03 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 745E455362 for ; Thu, 20 Jun 2013 12:11:03 +0300 (EEST) Message-ID: <51C2C729.3090204@ericsson.com> Date: Thu, 20 Jun 2013 12:11:05 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stox@ietf.org References: <51C23237.30203@stpeter.im> <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> In-Reply-To: <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvra728UOBBv8Ws1j839HE6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGedn9gLFslVHF7zkLmBcZF4FyMnh4SAicSeS61sELaYxIV7 64FsLg4hgVOMEvMaF0I5Gxgljs6dyApSJSRwkVFi5VMzCPsQo8SeZY4QRacZJe427WQESfAK aEts+vcRqJuDg0VAVeJmTzFImE3ATOL5wy3MILaoQLLE5KkrWCDKBSVOznwCZosA2Tf+3WIH sYUFTCU+d/UzQeyKk+jYsx3sBk4BZ4kTk5rA6pkFbCUuzLkOZctLNG+dzQzxjZrE1XObmCF6 tSR6z3YyTWAUmYVk3Swk7bOQtC9gZF7FyJ6bmJmTXm64iREYyAe3/NbdwXjqnMghRmkOFiVx 3g+ndgUKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYAy4oTzvVsq9XU2v86b9efXVqO92R8m7 uNWHXv0OV7xxpCdPw+ZYRkNbZIK098XtR599P82caqrtsW1/vNuRddOml346I/iWqzPmboDL Ju6tKnxKZ33lFWaEPHn7cedG9bb0pdNtQ1R877f9N/Q7ob5+1x2DxDzfv8abE9XPVOq777N7 3FKaMUeJpTgj0VCLuag4EQB6PpXKMgIAAA== Subject: Re: [Stox] core: connecting to remote domain X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 09:11:21 -0000 Hi, On 6/20/13 9:22 AM, Saúl Ibarra Corretgé wrote: > Hi! > > On Jun 20, 2013, at 12:35 AM, Peter Saint-Andre wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> While working on the sip-xmpp-groupchat spec today, Saúl and I found >> what I think is an open issue wiht the sip-xmpp-core spec: it doesn't >> say how you determine whether a remote domain supports SIP or XMPP (or >> both). This is needed for interdomain routing of messages. Thus I >> think the sip-xmpp-core spec needs to contain something like the text >> in Section 11.2 of RFC 3921: >> >> ### >> >> 11.2. Outbound Stanzas >> >> >> If the hostname of the domain identifier portion of the address >> contained in the 'to' attribute of an outbound stanza matches a >> hostname of the server itself, the server MUST deliver the stanza to >> a local entity according the rules for Inbound Stanzas (Section >> 11.1). >> >> If the hostname of the domain identifier portion of the address >> contained in the 'to' attribute of an outbound stanza does not match >> a hostname of the server itself, the server MUST attempt to route the >> stanza to the foreign domain. The recommended order of actions is as >> follows: >> >> 1. First attempt to resolve the foreign hostname using an [SRV] >> Service of "xmpp-server" and Proto of "tcp", resulting in >> resource records such as "_xmpp-server._tcp.example.com.", as >> specified in [XMPP-CORE]. >> >> 2. If the "xmpp-server" address record resolution fails, attempt to >> resolve the "_im" or "_pres" [SRV] Service as specified in >> [IMP-SRV], using the "_im" Service for stanzas and the >> "_pres" Service for stanzas (it is up to the >> implementation how to handle stanzas). This will result in >> one or more resolutions of the form "_im..example.com." or >> "_pres..example.com.", where "" would be a label >> registered in the Instant Messaging SRV Protocol Label registry >> or the Presence SRV Protocol Label registry: either "_xmpp" for >> an XMPP-aware domain or some other IANA-registered label (e.g., >> "_simple") for a non-XMPP-aware domain. >> >> 3. If both SRV address record resolutions fail, attempt to perform a >> normal IPv4/IPv6 address record resolution to determine the IP >> address using the "xmpp-server" port of 5269 registered with the >> IANA, as specified in [XMPP-CORE]. >> >> Administrators of server deployments are strongly encouraged to keep >> the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records properly >> synchronized, since different implementations might perform the "_im" >> and "_pres" lookups before the "xmpp-server" lookup. >> >> ### >> > Well, the problem is that in practice a given domain would have records for both SIP and XMPP, so which one would we check first? I'm not sure if we can define an unequivocal mechanism to choose the right target, so I'm tempted to suggest not to define it for the moment and leave it as a local policy item. if a domain has a record for both SIP and XMMP then if you are an XMPP client, it seems normal to me try first the XMPP one (and the other way around if I am a SIP UA) or I am missing something here? > If we come up with a way to do it later on, maybe we can create a new document updating sip-xmpp core? > >> However, we'd need text describing the discovery and decision process >> in both directions (and IMHO we need to drop the _im and _pres SRV >> stuff, as we did when working on RFC 6121). >> > I have never seen _im and _pres out in the wild, so I'm +1 on removing the mention to them. +1 on removing them /Salvatore From salvatore.loreto@ericsson.com Thu Jun 20 02:17:03 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F3D21E80FD for ; Thu, 20 Jun 2013 02:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.122 X-Spam-Level: X-Spam-Status: No, score=-105.122 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87, 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 UEp2lUlvLHal for ; Thu, 20 Jun 2013 02:16:54 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B356F21F9F45 for ; Thu, 20 Jun 2013 02:16:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-a5-51c2c8845c3f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 2F.4F.15700.488C2C15; Thu, 20 Jun 2013 11:16:52 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 20 Jun 2013 11:16:52 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EA62711041D for ; Thu, 20 Jun 2013 12:16:51 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 74CEA553A5 for ; Thu, 20 Jun 2013 12:16:49 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D825A55347 for ; Thu, 20 Jun 2013 12:16:48 +0300 (EEST) Message-ID: <51C2C882.5050107@ericsson.com> Date: Thu, 20 Jun 2013 12:16:50 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stox@ietf.org References: <51C23237.30203@stpeter.im> <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+JvrW7LiUOBBlufi1n839HE6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPuLtrAWbFCr6NyxjqWBcbVcFyMHh4SAicTWfZldjJxAppjE hXvr2boYuTiEBE4xSrTsvM0I4WxglNh8cT4LhHMRyPn7Fco5xChxvf8wK4RzmlHi8+W1zCBz eQW0JV6ftwSZyyKgKjFnzgdWEJtNwEzi+cMtzCC2qECyxOSpK1hAbF4BQYmTM5+A2SJA9o1/ t9hBbGEBU4nPXf1MEPOnMko8+TQbrJlTwFni4fftYEXMArYSF+ZcZ4Gw5SWat0LUSAioSVw9 twnMFhLQkug928k0gVFkFpJ9s5C0z0LSvoCReRUje25iZk56ueEmRmAwH9zyW3cH46lzIocY pTlYlMR5P5zaFSgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMS34dlCZcdf1W4YxNva3z7Ix K1hciJo9d8WCFbXcnke/tWY5lDa2MIa2abEwrU65t0vM8fvJ/REXr881tnkRxrJydu05q2+n lW7Zz1Y45SqcnJNzYbJLgjULn8yT142hK30sJASSBW0nqshe3nRuzl7vQ2ZGN6578TLEffC9 +1mp6ufzU1IKSizFGYmGWsxFxYkARn+zZjQCAAA= Subject: Re: [Stox] core: connecting to remote domain X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 09:17:03 -0000 On 6/20/13 9:28 AM, Adrian Georgescu wrote: > XMPP has defined DNS records for both C2S and S2S connections. One domain may have a server to server XMPP capability but would not accept client connections (missing correspondent DNS record), this would give me a clue that that foreign domain has such XMPP 2 SIP gateway in place and if I am a client of that domain I know I cannot use an XMPP client for it. sorry but what would be the reason to have (and expose thru DNS) an XMPP2SIP gateway and then not let it to be accessible from a client? are you assuming that a XMPP2SIP gateway is always only an outbound one? /Salvatore > For SIP however, is not clear as the same DNS records are used both by clients and servers to locate the Proxy/Registrar for a given domain. This is the missing piece that makes a heuristic approach not 100% accurate. > > Adrian > > > On Jun 20, 2013, at 8:22 AM, Saúl Ibarra Corretgé wrote: > >> Hi! >> >> On Jun 20, 2013, at 12:35 AM, Peter Saint-Andre wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> While working on the sip-xmpp-groupchat spec today, Saúl and I found >>> what I think is an open issue wiht the sip-xmpp-core spec: it doesn't >>> say how you determine whether a remote domain supports SIP or XMPP (or >>> both). This is needed for interdomain routing of messages. Thus I >>> think the sip-xmpp-core spec needs to contain something like the text >>> in Section 11.2 of RFC 3921: >>> >>> ### >>> >>> 11.2. Outbound Stanzas >>> >>> >>> If the hostname of the domain identifier portion of the address >>> contained in the 'to' attribute of an outbound stanza matches a >>> hostname of the server itself, the server MUST deliver the stanza to >>> a local entity according the rules for Inbound Stanzas (Section >>> 11.1). >>> >>> If the hostname of the domain identifier portion of the address >>> contained in the 'to' attribute of an outbound stanza does not match >>> a hostname of the server itself, the server MUST attempt to route the >>> stanza to the foreign domain. The recommended order of actions is as >>> follows: >>> >>> 1. First attempt to resolve the foreign hostname using an [SRV] >>> Service of "xmpp-server" and Proto of "tcp", resulting in >>> resource records such as "_xmpp-server._tcp.example.com.", as >>> specified in [XMPP-CORE]. >>> >>> 2. If the "xmpp-server" address record resolution fails, attempt to >>> resolve the "_im" or "_pres" [SRV] Service as specified in >>> [IMP-SRV], using the "_im" Service for stanzas and the >>> "_pres" Service for stanzas (it is up to the >>> implementation how to handle stanzas). This will result in >>> one or more resolutions of the form "_im..example.com." or >>> "_pres..example.com.", where "" would be a label >>> registered in the Instant Messaging SRV Protocol Label registry >>> or the Presence SRV Protocol Label registry: either "_xmpp" for >>> an XMPP-aware domain or some other IANA-registered label (e.g., >>> "_simple") for a non-XMPP-aware domain. >>> >>> 3. If both SRV address record resolutions fail, attempt to perform a >>> normal IPv4/IPv6 address record resolution to determine the IP >>> address using the "xmpp-server" port of 5269 registered with the >>> IANA, as specified in [XMPP-CORE]. >>> >>> Administrators of server deployments are strongly encouraged to keep >>> the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records properly >>> synchronized, since different implementations might perform the "_im" >>> and "_pres" lookups before the "xmpp-server" lookup. >>> >>> ### >>> >> Well, the problem is that in practice a given domain would have records for both SIP and XMPP, so which one would we check first? I'm not sure if we can define an unequivocal mechanism to choose the right target, so I'm tempted to suggest not to define it for the moment and leave it as a local policy item. If we come up with a way to do it later on, maybe we can create a new document updating sip-xmpp core? >> >>> However, we'd need text describing the discovery and decision process >>> in both directions (and IMHO we need to drop the _im and _pres SRV >>> stuff, as we did when working on RFC 6121). >>> >> I have never seen _im and _pres out in the wild, so I'm +1 on removing the mention to them. >> >> -- >> Saúl Ibarra Corretgé >> AG Projects >> >> >> >> _______________________________________________ >> stox mailing list >> stox@ietf.org >> https://www.ietf.org/mailman/listinfo/stox >> > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From Markus.Isomaki@nokia.com Thu Jun 20 03:37:13 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF18021F9A5B for ; Thu, 20 Jun 2013 03:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.446 X-Spam-Level: X-Spam-Status: No, score=-5.446 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] 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 vdUVOc4PFRDR for ; Thu, 20 Jun 2013 03:37:08 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 73EF621F9A6C for ; Thu, 20 Jun 2013 03:37:07 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5KAb4QG015514; Thu, 20 Jun 2013 13:37:04 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.49]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jun 2013 13:37:04 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.114]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.02.0328.011; Thu, 20 Jun 2013 10:38:44 +0000 From: To: , Thread-Topic: [Stox] core: connecting to remote domain Thread-Index: AQHObT1bGqwIFhVywUGThOPE2dMt4Zk+IrcAgAABpgCAAC7yAIAAFKTw Date: Thu, 20 Jun 2013 10:37:02 +0000 Message-ID: References: <51C23237.30203@stpeter.im> <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> <51C2C882.5050107@ericsson.com> In-Reply-To: <51C2C882.5050107@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IgddHNxpFrpWmlMbp4RmRYKuRBUI8Vhn3O3//74GRyzYbejcgK0GbepKbWimPwGBXBqeaeFewt/fv6npEucp6wbuu2ISmiyf3WEO7r38oi3BLjBNlot+9Rg+T74uVVspYKy9es0u+G8UPlU72iC4CLYClidIf4Ivqun+2G1YuhRUPwos8TfDSaBE7UD32qGpjxp/5Erz3boIaV376OLpzkB+14f6YO5rZHzgyAdsZ1Q4 x-originating-ip: [172.21.81.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2013 10:37:04.0258 (UTC) FILETIME=[1AD46620:01CE6DA2] X-Nokia-AV: Clean Subject: Re: [Stox] core: connecting to remote domain X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 10:37:14 -0000 Hi Sal, Salvatore Loreto wrote: >=20 > On 6/20/13 9:28 AM, Adrian Georgescu wrote: > > XMPP has defined DNS records for both C2S and S2S connections. One > > domain may have a server to server XMPP capability but would not accept > > client connections (missing correspondent DNS record), this would give= me a > > clue that that foreign domain has such XMPP 2 SIP gateway in place and = if I > > am a client of that domain I know I cannot use an XMPP client for it. > > sorry but what would be the reason to have (and expose thru DNS) an > XMPP2SIP gateway and then not let it to be accessible from a client? > are you assuming that a XMPP2SIP gateway is always only an outbound one? >=20 I suppose it would be the case where the domain only runs a SIP service int= ernally, and just offers an XMPP gateway to external domains. So, if you ha= ve an XMPP-only client, you would have to get an account for some other dom= ain to be able to communicate with this SIP-only domain. Markus From Markus.Isomaki@nokia.com Thu Jun 20 03:43:52 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4923521F9A81 for ; Thu, 20 Jun 2013 03:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] 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 Iwpebrhaj363 for ; Thu, 20 Jun 2013 03:43:47 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8853421F9A7D for ; Thu, 20 Jun 2013 03:43:47 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5KAhcHE018515; Thu, 20 Jun 2013 13:43:45 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Jun 2013 13:43:41 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.114]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0328.011; Thu, 20 Jun 2013 10:45:21 +0000 From: To: Thread-Topic: Alternative proposals (Was: RE: [Stox] Maturity of the documents) Thread-Index: Ac5tok//kgVN8l+dT8ud1B1CM+vTUA== Date: Thu, 20 Jun 2013 10:43:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: 0fDZ0/3bNBI7cufMZ514Mw7v5T9DeqPXUwgq+hqHlWvsNbqm9bn1IcG/eIdD5WzDEHxacMgxkTSaHo7geRSruutpnVAqMXt2bSsWp9tkweD2/g2gPS8RIfvdChxy0xRjPnF4mPi6jtn4braivOGyy9EbeXi5Osl6rodit/5n5BoHb7wJZ6G6EjEVHzkn0yOOyWX3dRxW5XKe2opPF/3eDV9+5pJo8GmoQ4MzEb/aWP2y/nwNgsyiT3+wkrMi79nPzdKGK9u5sqkyzDpEAloNzXzsLtdUx9yeYIIvPZYY07Q= x-originating-ip: [172.21.81.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2013 10:43:41.0497 (UTC) FILETIME=[079A4290:01CE6DA3] X-Nokia-AV: Clean Cc: stox@ietf.org Subject: [Stox] Alternative proposals (Was: RE: Maturity of the documents) X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 10:43:52 -0000 Hi,=20 Sure. So, if you are not happy with the set of current 'draft-saintandre-si= p-xmpp-' documents but would like to make your own proposal, please=20 1.) Raise the issues on the STOX list by June 30 and explain briefly what i= s the different approach you would like to propose. 2.) Submit a draft by the -00 deadline for IETF 87, that is July 8, so we c= an discuss that at the meeting. Please make sure your proposal fits the charter, which is quite focused. Markus > -----Original Message----- > From: ext Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: 19 June, 2013 17:31 > To: Isomaki Markus (Nokia-CIC/Espoo) > Cc: stox@ietf.org > Subject: Re: [Stox] Maturity of the documents >=20 > Sorry - I should have read all the emails as I see the deadline in this e= mail: > http://www.ietf.org/mail-archive/web/stox/current/msg00058.html > So, maybe just be explicit that this is the deadline for any alternative > proposals. >=20 > Thanks, > Mary. >=20 > On Wed, Jun 19, 2013 at 9:28 AM, Mary Barnes > wrote: > > I fully support this proposal. Although, there were concerns raised > > during chartering that it seemed that the WG would just fell swoop > > adopt this documents - I personally feel that enough time has elapsed > > for someone to do that if they had the intention. But, it might be > > good to set a deadline on this proposal for adopting these as WG > > documents and make that the same deadline for anyone with alternative > > proposals towards the milestones. > > > > Regards, > > Mary. > > > > On Wed, Jun 19, 2013 at 6:01 AM, wrote: > >> Hi, > >> > >> > >> > >> The chairs have started a consensus call on adopting the > >> 'draft-saintandre-sip-xmpp-' documents as WG items. Please send your > >> feedback on it by replying to the separate mail about the topic. > >> > >> > >> > >> Somewhat independently of the WG adoption, here is my current > >> understanding of the maturity of these documents (as a co-chair). > >> This is based on my own reading as well as discussion with some of the= co- > authors. > >> > >> > >> > >> These documents seem to be in a good shape and will mainly just need > >> reviews: > >> > >> > >> > >> saintandre-sip-xmpp-core > >> > >> saintandre-sip-xmpp-presence > >> > >> saintandre-sip-xmpp-im > >> > >> saintandre-sip-xmpp-chat > >> > >> > >> > >> This document still has open issues. The co-authors are already > >> working on an update, but further work will still be needed: > >> > >> > >> > >> saintandre-sip-xmpp-groupchat > >> > >> > >> > >> This document requires most work still. It is in my understanding the > >> most complex piece of these mappings: > >> > >> > >> > >> saintandre-sip-xmpp-media > >> > >> > >> > >> This is just a very informal categorization and people are of course > >> welcome to raise any issues or send improvement suggestions with any > >> of these documents still even if we adopt them as WG documents. > >> > >> > >> > >> Markus > >> > >> > >> > >> > >> _______________________________________________ > >> stox mailing list > >> stox@ietf.org > >> https://www.ietf.org/mailman/listinfo/stox > >> From ag@ag-projects.com Thu Jun 20 03:53:38 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A9421F9B84 for ; Thu, 20 Jun 2013 03:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, SARE_MLH_Stock1=0.87] 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 zOWbT78F3vpr for ; Thu, 20 Jun 2013 03:53:34 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id BA1C821F9B80 for ; Thu, 20 Jun 2013 03:53:33 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 33226B35DC; Thu, 20 Jun 2013 12:53:31 +0200 (CEST) Received: from ag-retina.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 53C63B017C; Thu, 20 Jun 2013 12:53:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Adrian Georgescu In-Reply-To: Date: Thu, 20 Jun 2013 12:53:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2015DC2B-E03A-4DD8-BB6E-51F26FD9C7FE@ag-projects.com> References: <51C23237.30203@stpeter.im> <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> <51C2C882.5050107@ericsson.com> To: X-Mailer: Apple Mail (2.1508) Cc: salvatore.loreto@ericsson.com, stox@ietf.org Subject: Re: [Stox] core: connecting to remote domain X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 10:53:38 -0000 On Jun 20, 2013, at 12:37 PM, wrote: > Hi Sal, >=20 > Salvatore Loreto wrote: >>=20 >> On 6/20/13 9:28 AM, Adrian Georgescu wrote: >>> XMPP has defined DNS records for both C2S and S2S connections. One >>> domain may have a server to server XMPP capability but would not = accept >>> client connections (missing correspondent DNS record), this would = give me a >>> clue that that foreign domain has such XMPP 2 SIP gateway in place = and if I >>> am a client of that domain I know I cannot use an XMPP client for = it. >>=20 >> sorry but what would be the reason to have (and expose thru DNS) an >> XMPP2SIP gateway and then not let it to be accessible from a client? If the gateway can accept XMPP client connections, I see no problem. Is = just that in my experience the XMPP client connections are handled by = the native XMPP server of the XMPP domain and the gateway has limited = functionality and will only be used for the translation to SIP and = nothing else. Of course one can have a monolith server that handles = everything but this does not change the topology of the call flow, there = are still two different functions, handling the C2S connection and = bridging outside to another server using a S2S connection. >> are you assuming that a XMPP2SIP gateway is always only an outbound = one? It s used for both directions of course, I cannot see why would be used = just in one direction. > I suppose it would be the case where the domain only runs a SIP = service internally, and just offers an XMPP gateway to external domains. This is my scenario. > So, if you have an XMPP-only client, you would have to get an account = for some other domain to be able to communicate with this SIP-only = domain. Yes, this is a scenario where an operator provides a service using only = one of the protocols (typically SIP) and only uses gateway for bridging = traffic transparently to other XMPP domains without users having to know = that the foreign user is using either SIP or XMPP. It is the SIP server = that has the logic to make this routing decision and the gateway has a = trusted relations ship with this server to avoid fraudulent usage of = such service. The clients only talk to their respective native servers, = not directly to the gateway. Same as clients do not talk directly to = PSTN gateways, they rely on their servers to make such decisions. =20 >=20 > Markus >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox >=20 From Markus.Isomaki@nokia.com Thu Jun 20 04:13:07 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4289621F9BF3 for ; Thu, 20 Jun 2013 04:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=0.647, 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 x9T79p1fn--q for ; Thu, 20 Jun 2013 04:13:01 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8277621F9A40 for ; Thu, 20 Jun 2013 04:13:01 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5KBCnrL012858; Thu, 20 Jun 2013 14:12:50 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Jun 2013 14:12:48 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.114]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0328.011; Thu, 20 Jun 2013 11:14:28 +0000 From: To: Thread-Topic: Mapping for media signaling: still about the scope Thread-Index: Ac5s3MA7fW54rEx1RRO+pgL1gkj4zQAOhceAACMblMA= Date: Thu, 20 Jun 2013 11:12:47 +0000 Message-ID: References: <51C1F1AB.1040701@jitsi.org> In-Reply-To: <51C1F1AB.1040701@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Iq9xe+e+++NbxF1V8stTnYynbVjG/ydnfSuhaS8gP4WfL+bGbFFp9FjeLabk9r94R43Pm/hs9DvNYy285qg67FfH4YOxiML8BIkMF7+p3S/NFFhQsptX0NCPXEnymSwVIECFCEKkcqeUI/dt7lX2ezv4O3nqGgDb9ToYx6p7eSKtxMkiLdn+M61bsrLJiLcDeXWA2qJsj4+4ZBhwX5LTCnOTl1STm+k+BiasoGHfcGSDB/bl+UcVNwo13PdjOwDkdw== x-originating-ip: [172.21.81.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2013 11:12:48.0872 (UTC) FILETIME=[191E8680:01CE6DA7] X-Nokia-AV: Clean Cc: stox@ietf.org, saul@ag-projects.com, stpeter@stpeter.im Subject: Re: [Stox] Mapping for media signaling: still about the scope X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 11:13:07 -0000 Hi Emil, See inline. Emil Ivov [mailto:emcho@jitsi.org] wrote: > On 19.06.13, 13:56, Markus.Isomaki@nokia.com wrote: > > Hi Emil, Saul, Peter, and others, > > > > Recently I raised some questions about the scope of the 'sip-xmpp-media= ' > > and the related deliverable on the 'mapping for media signaling': > > http://www.ietf.org/mail-archive/web/stox/current/msg00025.html > > > > Now that STOX is officially up and running I'd like us to make an > > actual plan on what the scope of this document should be, i.e. what > > features are explicitly going to be part of this mapping spec. > > Although people have successfully implemented SIP-to-XMPP media > > signaling gateways, I at least see this topic to have some complexity d= ue to: > > > > -SDP offer/answer is a moving target as new features are being added > > as we speak, >=20 > Well ... it is and it isn't. 3264 isn't really changing and all extension= s are > supposed to keep backward compatibility with it. >=20 Right. That's good. > > including "bundle" and "trickle-ICE". We can't know about what > > features will be added later on. >=20 > No, but we could include some that we know of ... like "bundle" and "tric= kle- > ICE" :). >=20 > Trickle ICE would be easier because we already have it in Jingle and the = SIP > version shouldn't take long. >=20 That's one of the "administrative" decisions we should make about the "firs= t release" of the media signaling mapping *RFC*. Do we only take in feature= s/extensions that are completed RFCs or XSF XEPs, so that we for quite big = certainty can get a mature document to IESG in October. And then extend it = with new features once they complete, perhaps one or two years later, perha= ps in multiple small steps. Or, do we already take features like "bundle" a= nd "trickle-ICE" in, and aim to get the document to IESG at some later poin= t, for instance March 2014. Trickle-ICE for SIP may not take long, but I be= t it will at least take longer than this WG is supposed to live ;-) I don't have an opinion about this as a co-chair. This is a question to peo= ple implementing and deploying the gateways or relying on them. What is the= most useful initial scope for you? How important it is to have an RFC out = this year vs. covering as many features as possible? I mean technically a d= raft might be as useful to an implementer as an RFC on those parts that are= stable while others are developed, but would there be some interoperabilit= y/technical/political/marketing/getting-actually-something-completed reason= to get an RFC out ASAP? The only guidance we have at this point is that our charter expects us to c= omplete in October, and in this case, unlike the normal IETF WG process, I = at least as a co-chair intend to take that seriously :-) > > -There are features currently supported in XMPP that are not currently > > supported in SIP (and perhaps vice versa?), such as the trickle-ICE > > support in Jingle. >=20 > As mentioned. I don't think trickle-ICE would be a problem. I believe > separating transport and encoding information would be a bigger hurdle bu= t > if we accept that urn:ietf:rfc:3264 means one shouldn't do this. >=20 > > -Regardless of what is supported in each protocol in general, the > > actual SIP and XMPP clients will support different sets of features. >=20 > Right. >=20 > > Ideally, some things might be mapped transparently in the gateway in > > an "algorithmic" manner. >=20 > I don't believe this would be possible. >=20 Good, then my understanding seems to be correct. > > And ideally, the clients supporting different feature sets can > > negotiate end-to-end without needing for the gateway to mediate. > > However, I'm not sure how easy this will be in practice. > > > > Actually one reason why I see these complications may be that I don't > > have a very good overall understanding about how SDP O/A (as in RFC > > 3264 syntax and semantics) is mapped to XMPP/Jingle (as in its XML > > based > > syntax) are in general kept "in synch". For instance, if IETF extends > > SDP O/A in some way, will that always require an explicit > > corresponding extension XEP by the XSF, or is there some more > > straightforward "algorithmic" way to convey something new on the > > SIP/SDP side to the XMPP/Jingle side. >=20 > Well, the good thing about O/A extensions is that they generally preserve > backward compatibility. This is valid for things like ICE, trickle ICE, r= tcp-mux, > bundle. So as long as we support 3264 we should be OK. I think :) >=20 Yes, let's stick to that theory ;-) ... >=20 > > -What will happen to features supported on one or either side of the > > gateway that the gateway is not aware of- can some things be > > "transparently" mapped or will the gateway become the "blocking factor" > > in the middle. (I.e., will the session setup be limited to the > > features the gateway explicitly needs to "understand".) >=20 > I don't think the gateway could just forward anything because this would > imply a straightforward mapping from any SDP attribute to a Jingle elemen= t. >=20 > Maybe gateways could behave as regular SIP B2BUAs: they forward the > things that they understand and they remove those that they don't > understand or support. >=20 OK, that simplifies things as well. (Again was just checking I'm not missin= g any end-to-end magic that might exist. But apparently not ;-) > Thoughts? >=20 > > -How will we extend the mapping spec in the future and how should the > > initial spec take this into account. >=20 > As in administratively? >=20 In some sense yes. I would expect perhaps some brief section that gives gui= delines to the authors who in the future want to extend this mapping spec w= ith some new feature. And would be rather do a full-fledged '-bis' spec at some point or a bunch = or incremental extension drafts on top of the baseline. As an example "An e= xtension to SIP-XMPP media signaling mapping to support trickle-ICE".=20 > Emil >=20 Markus From Markus.Isomaki@nokia.com Thu Jun 20 04:17:27 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2281421F9A7C for ; Thu, 20 Jun 2013 04:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, J_BACKHAIR_36=1, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] 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 1vQRIHjaKEZt for ; Thu, 20 Jun 2013 04:17:19 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B509921F9A7A for ; Thu, 20 Jun 2013 04:17:11 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5KBGumY011234; Thu, 20 Jun 2013 14:16:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jun 2013 14:16:56 +0300 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.114]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0328.011; Thu, 20 Jun 2013 11:18:36 +0000 From: To: , Thread-Topic: [Stox] Mapping for media signaling: features to cover Thread-Index: Ac5tp0JaTADbmA9hSSipYaKv52g/Rw== Date: Thu, 20 Jun 2013 11:16:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Iv/YdXDG3jsbgoPRJrYyGPl+RLUy5o34pe1STuA2RpMSuYFlOQSFEFKwOo13go9pUC7hWjI6Qxveoeb7esSJ2Cdh5PzfkoURmS1WqCbOfzSalC+ZkFc3ysTynr5T5Jm3JxQnMyqBUG5gMs49N6c8N20QVSLzH7pTsGwrAKD8L7hsDx5Uw1ufnaaNzb3wNZRL/d2HUtvwEY1wQcecQSrB+0fmwi2CjxsQNNhzxzRUH9wmUmsXZSl/B/3op9XcHaVmYg== x-originating-ip: [172.21.81.125] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2013 11:16:56.0196 (UTC) FILETIME=[AC892C40:01CE6DA7] X-Nokia-AV: Clean Subject: Re: [Stox] Mapping for media signaling: features to cover X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 11:17:27 -0000 Hi, To my understanding this is now the most relevant discussion to have regard= ing the STOX media signaling mapping draft. So, please send your input and = let's try to converge on this so that our authors-to-be Emil, Saul (and Pet= er) will know what to include in the next draft version. Markus > -----Original Message----- > From: stox-bounces@ietf.org [mailto:stox-bounces@ietf.org] On Behalf Of > ext Philipp Hancke > Sent: 19 June, 2013 21:16 > To: stox@ietf.org > Subject: Re: [Stox] Mapping for media signaling: still about the scope >=20 > Am 19.06.2013 20:00, schrieb Emil Ivov: [...] > > OK, so how about starting with 3261, 3264, 4585, 5285, 5761. >=20 > That is the core i'm using in my sdp<->jingle mapping for webrtc purposes= . > Add 4568 (sdes, a=3Dcrypto), 5763 (a=3Dfingerprint for dtls-srtp) and pos= sibly 5576 > (a=3Dssrc) to that list. >=20 > > I think we can also add trickle ICE since I don't believe we have much > > work left for SIP. > > > > Personally I wouldn't even mind having BUNDLE, we'd just need to have > > the feature in Jingle. >=20 > You can exploit the same-icepwd/ufrag property from > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation- > 04#section-8.1 > -- I haven't checked for backward compability issues though. That way it > seems we'd only need to have a disco feature for it along with a paragrap= h in > XEP-0176. >=20 > cheers >=20 > philipp > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox From stpeter@stpeter.im Thu Jun 20 10:55:58 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D008C21F8263 for ; Thu, 20 Jun 2013 10:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 L7LttWBzzLJp for ; Thu, 20 Jun 2013 10:55:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF8821F9EC3 for ; Thu, 20 Jun 2013 10:55:46 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D6B3C412C9; Thu, 20 Jun 2013 11:55:46 -0600 (MDT) Message-ID: <51C3421E.8020808@stpeter.im> Date: Thu, 20 Jun 2013 11:55:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adrian Georgescu References: <51C23237.30203@stpeter.im> <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> <51C2C882.5050107@ericsson.com> <2015DC2B-E03A-4DD8-BB6E-51F26FD9C7FE@ag-projects.com> In-Reply-To: <2015DC2B-E03A-4DD8-BB6E-51F26FD9C7FE@ag-projects.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: salvatore.loreto@ericsson.com, stox@ietf.org, Markus.Isomaki@nokia.com Subject: Re: [Stox] core: connecting to remote domain X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:55:58 -0000 On 6/20/13 4:53 AM, Adrian Georgescu wrote: > > On Jun 20, 2013, at 12:37 PM, wrote: > >> Hi Sal, >> >> Salvatore Loreto wrote: >>> >>> On 6/20/13 9:28 AM, Adrian Georgescu wrote: >>>> XMPP has defined DNS records for both C2S and S2S connections. >>>> One domain may have a server to server XMPP capability but >>>> would not accept client connections (missing correspondent DNS >>>> record), this would give me a clue that that foreign domain has >>>> such XMPP 2 SIP gateway in place and if I am a client of that >>>> domain I know I cannot use an XMPP client for it. >>> >>> sorry but what would be the reason to have (and expose thru DNS) >>> an XMPP2SIP gateway and then not let it to be accessible from a >>> client? > > If the gateway can accept XMPP client connections, I see no problem. > Is just that in my experience the XMPP client connections are handled > by the native XMPP server of the XMPP domain and the gateway has > limited functionality and will only be used for the translation to > SIP and nothing else. Of course one can have a monolith server that > handles everything but this does not change the topology of the call > flow, there are still two different functions, handling the C2S > connection and bridging outside to another server using a S2S > connection. > >>> are you assuming that a XMPP2SIP gateway is always only an >>> outbound one? > > It s used for both directions of course, I cannot see why would be > used just in one direction. > >> I suppose it would be the case where the domain only runs a SIP >> service internally, and just offers an XMPP gateway to external >> domains. > > This is my scenario. > >> So, if you have an XMPP-only client, you would have to get an >> account for some other domain to be able to communicate with this >> SIP-only domain. > > > Yes, this is a scenario where an operator provides a service using > only one of the protocols (typically SIP) and only uses gateway for > bridging traffic transparently to other XMPP domains without users > having to know that the foreign user is using either SIP or XMPP. It > is the SIP server that has the logic to make this routing decision > and the gateway has a trusted relations ship with this server to > avoid fraudulent usage of such service. The clients only talk to > their respective native servers, not directly to the gateway. Same as > clients do not talk directly to PSTN gateways, they rely on their > servers to make such decisions. Right, that makes sense. I was thinking about the interdomain communication: if the SIP user romeo@example.com sends a message to juliet@example.org, he doesn't need to know or care if Juliet uses SIP or XMPP, but the service at example.org needs to determine how it will route the message to Juliet (i.e., using SIP or XMPP). So it needs to complete some kind of discovery or it needs to be configured to "just know" that example.org is (say) a SIP service. However, while completing a copy edit on the groupchat spec this morning I noticed that we already have the following text: Upon receiving the INVITE, the SIP-to-XMPP gateway needs to determine the identity of the remote domain, which it does by performing one or more DNS SRV lookups [RFC2782]. The SIP-to-XMPP gateway SHOULD resolve the address present in the To header of the INVITE to an im URI, then follow the rules in [RFC3861] regarding the "_im" SRV service for the target domain contained in the To header. If SRV address resolution fails for the "_im" service, the SIP-to-XMPP gateway MAY attempt a lookup for the "_xmpp-server" service as specified in [RFC6120] or MAY return an error to the sender (i.e. 502 Bad Gateway). Now, that text is probably old (we've been working on these mapping specs for a long time) and thus probably predates the updated XMPP RFCs. If we're not going to recommend use of the "_im" and "_pres" SRV records, then connections to remote domains a likely a matter for implementation and deployment. However, I'd hate to do all this work on the mapping specs and then leave the hard federation bits up to folks in the field who might not be able to easily configure these services. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Jun 20 15:02:48 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4AF21F9FEA for ; Thu, 20 Jun 2013 15:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 kPbNBCUZeSgp for ; Thu, 20 Jun 2013 15:02:44 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 08A0A21F9FEC for ; Thu, 20 Jun 2013 15:02:43 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E79E7412C9; Thu, 20 Jun 2013 16:02:45 -0600 (MDT) Message-ID: <51C37C01.7020907@stpeter.im> Date: Thu, 20 Jun 2013 16:02:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "stox@ietf.org" References: <20130620220045.18629.97833.idtracker@ietfa.amsl.com> In-Reply-To: <20130620220045.18629.97833.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130620220045.18629.97833.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Stox] Fwd: I-D Action: draft-saintandre-sip-xmpp-groupchat-04.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:02:49 -0000 As promised, we've submitted a revised version of the groupchat spec. This closes all the open issues we know about. Reviews and feedback are welcome. Peter -------- Original Message -------- Subject: I-D Action: draft-saintandre-sip-xmpp-groupchat-04.txt Date: Thu, 20 Jun 2013 15:00:45 -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 : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat Author(s) : Peter Saint-Andre Saul Ibarra Salvatore Loreto Filename : draft-saintandre-sip-xmpp-groupchat-04.txt Pages : 32 Date : 2013-06-20 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-sip-xmpp-groupchat There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-groupchat-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-saintandre-sip-xmpp-groupchat-04 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 From ag@ag-projects.com Thu Jun 20 23:49:33 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1664111E8102 for ; Thu, 20 Jun 2013 23:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, SARE_MLH_Stock1=0.87] 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 fXbXPnuO5u32 for ; Thu, 20 Jun 2013 23:49:28 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8E921E8056 for ; Thu, 20 Jun 2013 23:49:27 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id A9B0DB35DD; Fri, 21 Jun 2013 08:49:26 +0200 (CEST) Received: from [192.168.1.6] (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 30512B017C; Fri, 21 Jun 2013 08:49:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <51C3421E.8020808@stpeter.im> Date: Fri, 21 Jun 2013 08:49:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <43FDD54B-A471-4F7C-A1C6-888A14271D0B@ag-projects.com> References: <51C23237.30203@stpeter.im> <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> <51C2C882.5050107@ericsson.com> <2015DC2B-E03A-4DD8-BB6E-51F26FD9C7FE@ag-projects.com> <51C3421E.8020808@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1283) Cc: salvatore.loreto@ericsson.com, stox@ietf.org, Markus.Isomaki@nokia.com Subject: Re: [Stox] core: connecting to remote domain X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 06:49:33 -0000 >> Yes, this is a scenario where an operator provides a service using >> only one of the protocols (typically SIP) and only uses gateway for >> bridging traffic transparently to other XMPP domains without users >> having to know that the foreign user is using either SIP or XMPP. It >> is the SIP server that has the logic to make this routing decision >> and the gateway has a trusted relations ship with this server to >> avoid fraudulent usage of such service. The clients only talk to >> their respective native servers, not directly to the gateway. Same as >> clients do not talk directly to PSTN gateways, they rely on their >> servers to make such decisions. >=20 > Right, that makes sense. >=20 > I was thinking about the interdomain communication: if the SIP user > romeo@example.com sends a message to juliet@example.org, he doesn't = need > to know or care if Juliet uses SIP or XMPP, but the service at > example.org needs to determine how it will route the message to Juliet > (i.e., using SIP or XMPP). So it needs to complete some kind of > discovery or it needs to be configured to "just know" that example.org > is (say) a SIP service. >=20 > However, while completing a copy edit on the groupchat spec this = morning > I noticed that we already have the following text: >=20 > Upon receiving the INVITE, the SIP-to-XMPP gateway needs to = determine > the identity of the remote domain, which it does by performing one = or > more DNS SRV lookups [RFC2782]. The SIP-to-XMPP gateway SHOULD > resolve the address present in the To header of the INVITE to an im > URI, then follow the rules in [RFC3861] regarding the "_im" SRV > service for the target domain contained in the To header. If SRV > address resolution fails for the "_im" service, the SIP-to-XMPP > gateway MAY attempt a lookup for the "_xmpp-server" service as > specified in [RFC6120] or MAY return an error to the sender (i.e. = 502 > Bad Gateway). In practice we do lookup _xmmp_server, I personally never saw a = deployment of those _im records in the real world as of yet but others = may confirm if this is the rule or the exception. Does anyone know a = public service using those? > Now, that text is probably old (we've been working on these mapping > specs for a long time) and thus probably predates the updated XMPP = RFCs. > If we're not going to recommend use of the "_im" and "_pres" SRV > records, then connections to remote domains a likely a matter for > implementation and deployment. It is a matter of implementation > However, I'd hate to do all this work on > the mapping specs and then leave the hard federation bits up to folks = in > the field who might not be able to easily configure these services. Nothing breaks if a gateway tries to lookup those records too, it is = harmless yet useless as far as I can see because of lack of adoption.=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox >=20 From stpeter@stpeter.im Fri Jun 21 05:32:06 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BC221F9F97 for ; Fri, 21 Jun 2013 05:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 9soU-0GK+cFT for ; Fri, 21 Jun 2013 05:32:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B291A21F9F8D for ; Fri, 21 Jun 2013 05:32:01 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 93ECB412C3; Fri, 21 Jun 2013 06:32:05 -0600 (MDT) Message-ID: <51C447C2.3090809@stpeter.im> Date: Fri, 21 Jun 2013 06:32:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adrian Georgescu References: <51C23237.30203@stpeter.im> <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com> <51C2C882.5050107@ericsson.com> <2015DC2B-E03A-4DD8-BB6E-51F26FD9C7FE@ag-projects.com> <51C3421E.8020808@stpeter.im> <43FDD54B-A471-4F7C-A1C6-888A14271D0B@ag-projects.com> In-Reply-To: <43FDD54B-A471-4F7C-A1C6-888A14271D0B@ag-projects.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: salvatore.loreto@ericsson.com, stox@ietf.org, Markus.Isomaki@nokia.com Subject: Re: [Stox] core: connecting to remote domain X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 12:32:06 -0000 On 6/21/13 12:49 AM, Adrian Georgescu wrote: >>> Yes, this is a scenario where an operator provides a service >>> using only one of the protocols (typically SIP) and only uses >>> gateway for bridging traffic transparently to other XMPP domains >>> without users having to know that the foreign user is using >>> either SIP or XMPP. It is the SIP server that has the logic to >>> make this routing decision and the gateway has a trusted >>> relations ship with this server to avoid fraudulent usage of such >>> service. The clients only talk to their respective native >>> servers, not directly to the gateway. Same as clients do not talk >>> directly to PSTN gateways, they rely on their servers to make >>> such decisions. >> >> Right, that makes sense. >> >> I was thinking about the interdomain communication: if the SIP >> user romeo@example.com sends a message to juliet@example.org, he >> doesn't need to know or care if Juliet uses SIP or XMPP, but the >> service at example.org needs to determine how it will route the >> message to Juliet (i.e., using SIP or XMPP). So it needs to >> complete some kind of discovery or it needs to be configured to >> "just know" that example.org is (say) a SIP service. >> >> However, while completing a copy edit on the groupchat spec this >> morning I noticed that we already have the following text: >> >> Upon receiving the INVITE, the SIP-to-XMPP gateway needs to >> determine the identity of the remote domain, which it does by >> performing one or more DNS SRV lookups [RFC2782]. The SIP-to-XMPP >> gateway SHOULD resolve the address present in the To header of the >> INVITE to an im URI, then follow the rules in [RFC3861] regarding >> the "_im" SRV service for the target domain contained in the To >> header. If SRV address resolution fails for the "_im" service, the >> SIP-to-XMPP gateway MAY attempt a lookup for the "_xmpp-server" >> service as specified in [RFC6120] or MAY return an error to the >> sender (i.e. 502 Bad Gateway). > > In practice we do lookup _xmmp_server, I personally never saw a > deployment of those _im records in the real world as of yet but > others may confirm if this is the rule or the exception. Does anyone > know a public service using those? I deployed them at jabber.org, but we might be the only ones. :-) >> Now, that text is probably old (we've been working on these >> mapping specs for a long time) and thus probably predates the >> updated XMPP RFCs. If we're not going to recommend use of the "_im" >> and "_pres" SRV records, then connections to remote domains a >> likely a matter for implementation and deployment. > > It is a matter of implementation Although I'd like to have something more automated, I think you're right. >> However, I'd hate to do all this work on the mapping specs and then >> leave the hard federation bits up to folks in the field who might >> not be able to easily configure these services. > > Nothing breaks if a gateway tries to lookup those records too, it is > harmless yet useless as far as I can see because of lack of adoption. Sadly, yes. Peter -- Peter Saint-Andre https://stpeter.im/ From Markus.Isomaki@nokia.com Fri Jun 28 01:22:40 2013 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01CB21F9D58 for ; Fri, 28 Jun 2013 01:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 WPoLMLsGJzs9 for ; Fri, 28 Jun 2013 01:22:27 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id ABC9421F9C0D for ; Fri, 28 Jun 2013 01:22:22 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5S8Llec008906 for ; Fri, 28 Jun 2013 11:22:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Jun 2013 11:22:08 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.76]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0328.011; Fri, 28 Jun 2013 08:23:53 +0000 From: To: Thread-Topic: Meeting in Berlin on Thu at 17:00 Thread-Index: Ac5z1+gSvhVaQhkBRXia4P0K6Cd4jA== Date: Fri, 28 Jun 2013 08:23:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: aZMi/WbTZrlATXhBcdW5gYwiBD/k/pMY4WT2hNRq0faZ3jkJlCXHeNvEdizmwsKQeyBTAFCayz9GbRABf6NoXELpSDuB4LR2rgvXcf/aZAmG1DScPoiwz+mUJiedX9z40N8tJkEyNbB4H0vl+zvzMWBJDZcpOWG0hfwaWcX9kroMI/e75CVu2HhaeB34dkHHErUce9IIEmPqF8OJeBagngtClFtg2nKQqS9k5woFppnxo4hyn3ji3Ii82YWRF/lk x-originating-ip: [10.163.160.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jun 2013 08:22:09.0010 (UTC) FILETIME=[94FD9520:01CE73D8] X-Nokia-AV: Clean Subject: [Stox] Meeting in Berlin on Thu at 17:00 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 08:22:40 -0000 Hi, Please notice: In the preliminary agenda for IETF 87, STOX WG has been reserved a slot at = the 1700-1830 session on Thursday: http://tools.ietf.org/agenda/87/#THURSDAY Markus=20