From Markus.Isomaki@nokia.com Tue Feb 1 03:33:55 2011 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68C93A6CC0 for ; Tue, 1 Feb 2011 03:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=-1.213, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qr8NWv-vujG for ; Tue, 1 Feb 2011 03:33:54 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 873AA3A6CC6 for ; Tue, 1 Feb 2011 03:33:54 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p11Bb9KZ026777; Tue, 1 Feb 2011 13:37:10 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 13:37:04 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 Feb 2011 12:37:03 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Tue, 1 Feb 2011 12:36:59 +0100 From: To: , , Thread-Topic: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02 Thread-Index: AQHLvZTBMsVG7EQwQ06Q+aXi3KtO9ZPjrp/wgADIKnCACBBjAA== Date: Tue, 1 Feb 2011 11:36:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Feb 2011 11:37:04.0764 (UTC) FILETIME=[598383C0:01CBC204] X-Nokia-AV: Clean Subject: Re: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02 X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 11:33:56 -0000 Hi John, John Elwell wrote: >The requirements look reasonable. I would like to see some solution >proposals, to help gauge whether the requirements are reasonable and >sufficient. For one approach you can take a look at an old draft we did: http://tools.ietf.org/id/draft-veikkolainen-sip-voip-xmpp-im-01.txt For protocol proposals and operation, see Chapter 5 onwards. Please comment if you think that track would be reasonable to meet some/mos= t of the requirements. Markus >-----Original Message----- >From: sixpac-bounces@ietf.org [mailto:sixpac-bounces@ietf.org] On Behalf >Of ext Elwell, John >Sent: 27 January, 2011 12:09 >To: Veikkolainen Simo (Nokia-MS/Helsinki); sixpac@ietf.org >Subject: Re: [sixpac] FW: New Version Notification for draft- >veikkolainen-sip-xmpp-coex-reqs-02 > >The requirements look reasonable. I would like to see some solution >proposals, to help gauge whether the requirements are reasonable and >sufficient. > >Just a few minor comments: >1. "Offering overlapping services (e.g. > presence) via both SIP and XMPP is out of scope of this document." >The term "overlapping" is not entirely clear on its own. Perhaps it >might be better to say: >"Offering the same service (e.g., presence) via both SIP and XMPP....". > >2. "We assume that the user initially only needs to know the contact > address of the other user in one protocol space. The contact address > for the other protocol must be learned by some means." >The second sentence doesn't make it clear that this discovery is within >the scope of SIXPAC. I would suggest: >"Discovering the contact address for the other protocol is within the >scope of this work." > >3. "When > an integrated endpoint communicates with a separated endpoint, normal > SIP and XMPP procedures apply and no extensions defined in this memo > are used." >In fact the integrated endpoint might attempt to use SIXPAC extensions, >but would fall back to using basic SIP/XMPP. Also "this memo" does not >define extensions, only requirements. >I would suggest: >"When an integrated endpoint communicates with a separated endpoint, >they should fall back to using normal SIP and XMPP procedures." > >4. " A user who has obtained another user's SIP URI is able to discover > the other user's XMPP URI so that she can send the other user XMPP > IM or subscribe to the other user's presence, or just populate her > address book for futher use. The user is able to do this without > bothering the other user, provided the other user has pre- > authorized the operation." >Should this be a 4th bullet, rather than an ordinary paragraph extending >the 3rd bullet? > >5. "REQ-4: It must be possible for a user, who only knows another >user's > SIP URI, to learn the other user's XMPP URI." >Is there a particular reason this is asymmetrical? Should there also be >a requirement for a user who knows another user's XMPP URI to learn that >user's SIP URI? > >John > >> -----Original Message----- >> From: sixpac-bounces@ietf.org >> [mailto:sixpac-bounces@ietf.org] On Behalf Of >> Simo.Veikkolainen@nokia.com >> Sent: 26 January 2011 20:20 >> To: sixpac@ietf.org >> Subject: [sixpac] FW: New Version Notification for >> draft-veikkolainen-sip-xmpp-coex-reqs-02 >> >> You're right, we should get some discussion going on. >> >> I have just uploaded a new version of >> draft-veikkolainen-sip-xmpp-coex-reqs, which can be found at >> http://www.ietf.org/internet-drafts/draft-veikkolainen-sip-xmp >> p-coex-reqs-02.txt >> >> The changes in this version address the comments made by >> Peter Musgrave (mainly clarifications): >> >> In REQ-1: "SIP contact" changed to "SIP address" >> >> In REQ-3: "It must be possible to include SIP real-time media >> related contact and status in XMPP presence information." >> changed to "It must be possible to include SIP address and >> status information in XMPP presence." >> >> And a couple of typos. >> >> One further comment made by Peter might merit a bit more >> discussion, namely saying something about cases where two SIP >> devices are registered to the same AOR and two XMPP clients >> are logged in. This is related to the discussion we had an >> correlation, and whether or not it should be mentioned in the >> charter or not. >> >> Opinions on this would be helpful. >> >> Also, please take a fresh look at the draft and express your >> opinions on whether the approach in general makes sense, do >> you agree with the use cases and requirements, is something >> missing etc. >> >> Thanks >> Simo >> >> >> -----Original Message----- >> From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> Sent: 26 January, 2011 22:05 >> To: Veikkolainen Simo (Nokia-MS/Helsinki) >> Cc: Isomaki Markus (Nokia-CIC/Espoo) >> Subject: New Version Notification for >> draft-veikkolainen-sip-xmpp-coex-reqs-02 >> >> >> A new version of I-D, >> draft-veikkolainen-sip-xmpp-coex-reqs-02.txt has been >> successfully submitted by Simo Veikkolainen and posted to the >> IETF repository. >> >> Filename: draft-veikkolainen-sip-xmpp-coex-reqs >> Revision: 02 >> Title: Requirements and Use Cases for >> Combining SIP Based Real-time Media Sessions With XMPP Based >> Instant Messaging and Presence Service. >> Creation_date: 2011-01-26 >> WG ID: Independent Submission >> Number_of_pages: 8 >> >> Abstract: >> This memo defines use cases and requirements for combining Session >> Initiation Protocol (SIP) based real-time media sessions with >> Extensible Messaging and Presence Protocol (XMPP) based instant >> messaging and presence services in a seamless manner. >> >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> sixpac mailing list >> sixpac@ietf.org >> https://www.ietf.org/mailman/listinfo/sixpac >> >_______________________________________________ >sixpac mailing list >sixpac@ietf.org >https://www.ietf.org/mailman/listinfo/sixpac From Markus.Isomaki@nokia.com Tue Feb 1 03:44:48 2011 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7C03A6CBF for ; Tue, 1 Feb 2011 03:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-1.146, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRRzdt8hWDn7 for ; Tue, 1 Feb 2011 03:44:47 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id A42FC3A6914 for ; Tue, 1 Feb 2011 03:44:47 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p11Blras000690 for ; Tue, 1 Feb 2011 13:48:03 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 13:47:54 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 Feb 2011 12:47:54 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Tue, 1 Feb 2011 12:47:53 +0100 From: To: , Thread-Topic: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02 Thread-Index: AQHLvZTBMsVG7EQwQ06Q+aXi3KtO9ZPjrp/wgAjfw/A= Date: Tue, 1 Feb 2011 11:47:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 01 Feb 2011 11:47:54.0696 (UTC) FILETIME=[DCE74480:01CBC205] X-Nokia-AV: Clean Subject: Re: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02 X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 11:44:48 -0000 SGkgYWxsLA0KDQpTaW1vIFZlaWtrb2xhaW5lbiB3cm90ZToNCj4NCj5JIGhhdmUganVzdCB1cGxv YWRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LXZlaWtrb2xhaW5lbi1zaXAteG1wcC1jb2V4LQ0K PnJlcXMsIHdoaWNoIGNhbiBiZSBmb3VuZCBhdCBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC0NCj52ZWlra29sYWluZW4tc2lwLXhtcHAtY29leC1yZXFzLTAyLnR4dA0K Pg0KPlRoZSBjaGFuZ2VzIGluIHRoaXMgdmVyc2lvbiBhZGRyZXNzIHRoZSBjb21tZW50cyBtYWRl IGJ5IFBldGVyIE11c2dyYXZlDQo+KG1haW5seSBjbGFyaWZpY2F0aW9ucyk6DQo+DQoNCkl0IHdv dWxkIGJlIGdvb2QgaWYgd2UgZ290IGEgZmV3IG1vcmUgcmV2aWV3cyBvbiB0aGlzIHJlcXVpcmVt ZW50cyBhbmQgdXNlIGNhc2VzIGRyYWZ0IHRvIHNlZSB0aGF0IHdlIGFncmVlIG9uIHRoZW0uIFNv IGZhciB3ZSBoYXZlIHJldmlld3MgZG9uZSBieSBQZXRlciBNdXNncmF2ZSBhbmQgSm9obiBFbHdl bGwgKGluIGFkZGl0aW9uIHRvIHRoZSBhdXRob3JzKSwgYnV0IGluIHRoZSBJRVRGIDc5IGFkIGhv YyBtZWV0aW5nLCBhbmQgb24gdGhlIERJU1BBVENIIGxpc3QsIHRoZXJlIHdlcmUgcXVpdGUgYSBm ZXcgb3RoZXIgaW50ZXJlc3RlZCBwZW9wbGUgYXMgd2VsbC4NCg0KU28sIHBsZWFzZSByZXZpZXcg dGhlIGRyYWZ0IGFuZCBzZW5kIHlvdXIgY29tbWVudHMuIEJhc2VkIG9uIHRob3NlIHdlIGNhbiBk byBhIGNvdXBsZSBvZiByZXZpc2lvbnMsIGFuZCBpZiBhZnRlciB0aGF0IHRoZXJlIGlzIGEgY29u c2Vuc3VzIG9uIHRoZSByZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcywgd2UgY2FuIG1vdmUgdG8g dGhlIG5leHQgcGhhc2UgYW5kIHN0YXJ0IHRoZSByZWFsIHdvcmsgb24gcHJvdG9jb2wgKGV4dGVu c2lvbikgcHJvcG9zYWxzLg0KDQpNYXJrdXMgDQo= From Markus.Isomaki@nokia.com Tue Feb 1 03:56:39 2011 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A24A3A6CC7 for ; Tue, 1 Feb 2011 03:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZite0pvcDsK for ; Tue, 1 Feb 2011 03:56:38 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 2D66C3A6CC6 for ; Tue, 1 Feb 2011 03:56:37 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p11BxrPT004697; Tue, 1 Feb 2011 13:59:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 13:59:49 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 Feb 2011 12:59:48 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi; Tue, 1 Feb 2011 12:59:47 +0100 From: To: , , Thread-Topic: Resolving SIP/XMPP URIs Thread-Index: AQHLwgeGeNM0i3/v7kqPya3/zXRKmw== Date: Tue, 1 Feb 2011 11:59:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Feb 2011 11:59:49.0097 (UTC) FILETIME=[86B83590:01CBC207] X-Nokia-AV: Clean Subject: [sixpac] Resolving SIP/XMPP URIs X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 11:56:39 -0000 Hi, John Elwell wrote: > >5. "REQ-4: It must be possible for a user, who only knows another >user's > SIP URI, to learn the other user's XMPP URI." >Is there a particular reason this is asymmetrical? Should there also be >a requirement for a user who knows another user's XMPP URI to learn that >user's SIP URI? > >From requirements and user experience perspective this should be symmetric,= so I would agree adding that to the requirements. The actual protocol realization may be more challenging. In the SIXPAC "mod= el" presence information is exchanged via XMPP. So, if a SIXPAC client know= s an XMPP address, it can conveniently use presence to learn about the corr= esponding SIP address (using the envisioned presence data extensions). But = if the SIXPAC client knows a SIP address to start with, what would be prefe= rred way for learning the corresponding XMPP address? Would SIP OPTIONS be = a good approach? That's the only realistically deployable method that I can= think of. Can we assume OPTIONS would work at least to a reasonable extent= between SIP UAs in current SIP deployments? (On paper it does, but unfortu= nately we always need to ask this question due to the deployment realities.= ..) Markus From Markus.Isomaki@nokia.com Tue Feb 1 04:39:13 2011 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49573A6938 for ; Tue, 1 Feb 2011 04:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7Ic6exqXvVT for ; Tue, 1 Feb 2011 04:39:12 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 30A413A6900 for ; Tue, 1 Feb 2011 04:39:11 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p11CgPZr027170 for ; Tue, 1 Feb 2011 14:42:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 14:42:20 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 Feb 2011 13:42:19 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Tue, 1 Feb 2011 13:42:18 +0100 From: To: Thread-Topic: Chartering... Thread-Index: AQHLwg12Ea6H6YfOHk+8HzA5r5+Idw== Date: Tue, 1 Feb 2011 12:42:13 +0000 Message-ID: References: <4CDB9E64.6070704@stpeter.im> In-Reply-To: <4CDB9E64.6070704@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {50790E06-92B4-4714-AC04-A77364C2DBF1} x-cr-hashedpuzzle: AkJ9 A4yW A+vK BzcC Cb7/ DKmL DqoY D/v3 E0bO FpMO HVGU Hh9U H4rL IsgK Jc8f JiHv; 1; cwBpAHgAcABhAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {50790E06-92B4-4714-AC04-A77364C2DBF1}; bQBhAHIAawB1AHMALgBpAHMAbwBtAGEAawBpAEAAbgBvAGsAaQBhAC4AYwBvAG0A; Tue, 01 Feb 2011 12:42:13 GMT;QwBoAGEAcgB0AGUAcgBpAG4AZwAuAC4ALgA= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 01 Feb 2011 12:42:20.0310 (UTC) FILETIME=[775C6B60:01CBC20D] X-Nokia-AV: Clean Subject: [sixpac] Chartering... X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 12:39:13 -0000 SGkgYWxsLA0KDQpXaGF0IGNvbWVzIHRvIHRoZSBTSVhQQUMgY2hhcnRlciBwcm9wb3NhbCwgdGhl IGxhdGVzdCB2ZXJzaW9uIChmcm9tIE5vdmVtYmVyKSBpcyBpbmNsdWRlZCBiZWxvdy4NCg0KSSB0 aGluayB0aGVyZSB3YXMgYSBwcmV0dHkgZ29vZCBhZ3JlZW1lbnQgb24gdGhpcyB2ZXJzaW9uLCBi dXQgSSB0aGluayB0aGVyZSBhcmUgdGhyZWUgc3BlY2lmaWMgaXNzdWVzIGFib3V0IGl0Og0KDQox LiBJcyB0aGVyZSBlbm91Z2ggZW5lcmd5IHRvIGdldCB0aGUgd29yayBkb25lPw0KDQpJIGRvbid0 IGtub3cgaG93IG1hbnkgcGVvcGxlIGFyZSBvbiB0aGlzIGxpc3QgKFBldGVyLCBhbnkgZXN0aW1h dGU/KSwgYnV0IHRoZXJlIHdlcmUgZW5vdWdoIHBlb3BsZSB3aG8gKnNhaWQqIHRoZXkgd2FudCB0 byBnZXQgdGhpcyBkb25lLiBJIGd1ZXNzIG5vdyB0aGUgYmVzdCB3YXkgdG8gc2hvdyBjb21taXRt ZW50IGFuZCBtYWtlIHByb2dyZXNzIGlzIHRvIHJldmlldyB0aGUgUmVxdWlyZW1lbnRzIGFuZCBV c2UgQ2FzZXMgZHJhZnQgKHNlZSBteSBlYXJsaWVyIG1haWwpIGFuZCBzZW5kIGNvbW1lbnRzIG9u IGl0Lg0KDQoyLiBUaGUgY2xpZW50IGNvbmZpZ3VyYXRpb24gcGFydCB3YXMgZHJvcHBlZC4gSXMg dGhhdCBPSz8NCg0KVGhlcmUgd2FzIG5vdCByZWFsbHkgYSBjb21tb24gdW5kZXJzdGFuZGluZyBv biB3aGF0IHRoZSBncm91cCB3b3VsZCBkbywgc28gdGhlIHRleHQgd2FzIHByb25lIHRvIG1pc3Vu ZGVyc3RhbmRpbmdzLiBJIGRvbid0IHRoaW5rIGFueW9uZSdzIGludGVudGlvbiB3YXMgdG8gZGVz aWduIHNvbWV0aGluZyBjb21wbGV0ZWx5IG5ldyBqdXN0IGZvciBTSVhQQUMgY2xpZW50cy4gU0lQ IGhhcyBjZXJ0YWluIGF1dG8tY29uZmlnIG1ldGhvZHMgKHN1Y2ggYXMgdGhlIHJlY2VudCBTSVAg Rm9ydW0gLyBJRVRGIHN0YW5kYXJkKSwgYW5kIHNvIGRvZXMgWE1QUC4gSWYgd2Ugc2VlIGl0IHVz ZWZ1bCB0byByZWNvbW1lbmQgc29tZXRoaW5nIGFib3V0IHRoZWlyIHVzZSBieSBTSVhQQUMgY2xp ZW50cywgSSB0aGluayB3ZSBjYW4gZG8gc28gYWxvbmcgdGhlc2UgbGluZXMgKGFzIGluY2x1ZGVk IGluIHRoZSBjaGFydGVyIHByb3Bvc2FsIG5vdyk6DQoNCj50aGUgZ3JvdXAgbWF5IGFsc28gZGVm aW5lIGJlc3QgcHJhY3RpY2VzIHJlbGF0ZWQgdG8gdGhlDQo+aW1wbGVtZW50YXRpb24gYW5kIGRl cGxveW1lbnQgb2YgZHVhbC1zdGFjayBTSVAvWE1QUCBlbmRwb2ludHMuDQoNCjMuIENvcnJlbGF0 aW9uIGFuZCBTSVAgZGVwbG95bWVudCByZWFsaXR5IChCMkJVQXMsIFNCQ3MsIC4uLikNCg0KU29t ZSBwZW9wbGUgdGhpbmsgdGhhdCB0aGUgImNvcnJlbGF0aW9uIGJldHdlZW4gYW4gWE1QUCBJTSBz ZXNzaW9uIGFuZCBhIFNJUCB2b2ljZSBvciB2aWRlbyBzZXNzaW9uIiBpcyBvbmx5IGdvaW5nIHRv IHdvcmsgaW4gInN0YW5kYXJkcyBjb21wbGlhbnQiIFNJUCBuZXR3b3Jrcywgd2hpY2ggbWF5IG5v dCBleGlzdCBkdWUgdG8gdGhlIGV4Y2Vzc2l2ZSBkZXBsb3ltZW50IG9mIFNCQ3MgYW5kIG90aGVy IHR5cGVzIG9mIEIyQlVBLCB3aG8gc3RyaXAgb3V0IG9yIG92ZXJyaWRlIGVuZC10by1lbmQgZGF0 YSBiZXR3ZWVuIFNJUCBVQXMuIFRoaXMgaXMgY2VydGFpbmx5IGEgcmlzaywgYnV0IGZvcnR1bmF0 ZWx5IEkgdGhpbmsgaW4gbW9zdCBjYXNlcyB0aGUgY29ycmVsYXRpb24gaXMganVzdCBhbiBvcHRp bWl6YXRpb24vbmljZS10by1oYXZlIGZlYXR1cmUsIGFuZCBldmVuIGlmIGl0IGZhaWxzIG9uIHNv bWUgb3IgZXZlbiBtb3N0IHNlc3Npb25zLCB3ZSB3aWxsIG5vdCBydWluIHRoZSB1c2VyIGV4cGVy aWVuY2UgKGl0IHdpbGwgYmUgYW55d2F5IGJldHRlciB3aXRoIFNJWFBBQyB0aGFuIGNvbXBsZXRl bHkgaXNvbGF0ZWQgU0lQIGFuZCBYTVBQIGNsaWVudHMpLiBJbiB0aGUgZW5kIEkgdGhpbmsgd2Ug c2hvdWxkIGhlcmUgb25seSB3b3JyeSBhYm91dCB1c2VyIGV4cGVyaWVuY2UsIG5vdCBnZXQgaW50 byB0aGUgcGhpbG9zb3BoaWNhbCBkaXNjdXNzaW9uIGFib3V0IFNCQ3MuIFdlIHNob3VsZCBhbHNv IG1ha2Ugc3VyZSBvdXIgY29ycmVsYXRpb24gbWV0aG9kIGlzIHN0cmFpZ2h0LXRvLXRoZS1wdXJw b3NlIChTSVhQQUMpIGFuZCBub3Qgc29tZSBraW5kIG9mIGdlbmVyaWMgZnJhbWV3b3JrIGEgbGEg c2Vzc2lvbiBpZCBvciBzcGxpY2VzIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQsIHRoYXQgd2lsbCBv cGVuIGRvb3JzIHRvIGFsbCBraW5kcyBvZiBjb25zcGlyYWN5IHRoZW9yaWVzIHdoYXQgaXQgY2Fu IGFsc28gYmUgdXNlZCBmb3IuDQoNClNvLCBmcm9tIG15IHBlcnNwZWN0aXZlIHRoZSBjaGFydGVy IHRleHQgaXMgZ29vZCAoZW5vdWdoKSBhcyBpdCBpcyBub3csIGFuZCB3ZSBvbmx5IG5lZWQgdG8g d29ycnkgYWJvdXQgcG9pbnQgMSAodHJhY2sgcmVjb3JkIHNvIGZhciBoYXMgbm90IGJlZW4gdGhh dCBpbXByZXNzaXZlIGR1ZSB0byB2YXJpb3VzIHJlYXNvbnMpLg0KDQpBbnkgY29tbWVudHM/IEhh dmUgSSBtaXNzZWQgb3RoZXIgaXNzdWVzL3JhdGhvbGVzIGFib3V0IHRoZSBjaGFydGVyPw0KDQpN YXJrdXMgDQoNCg0KPg0KPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj0NCj5TSVhQQUMgKFNJUCBJbnRlZ3Jh dGlvbiB3aXRoIFhNUFAgaW4gUHJlc2VuY2UgQXdhcmUgQ2xpZW50cykNCj49PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCj49DQo+DQo+UHJvYmxlbSBTdGF0ZW1lbnQNCj4NCj5Cb3RoIHRoZSBTZXNzaW9uIEluaXRp YXRpb24gUHJvdG9jb2wgKFNJUCkgYW5kIHRoZSBFeHRlbnNpYmxlIE1lc3NhZ2luZw0KPmFuZCBQ cmVzZW5jZSBQcm90b2NvbCAoWE1QUCkgYXJlIHdpZGVseSBkZXBsb3llZCB0ZWNobm9sb2dpZXMg Zm9yIHJlYWwtDQo+dGltZSBjb21tdW5pY2F0aW9uIG92ZXIgdGhlIEludGVybmV0LiAgSW4gb3Jk ZXIgdG8gb2ZmZXIgYSBjb21wbGV0ZQ0KPnN1aXRlIG9mIGZlYXR1cmVzIGFzIHdlbGwgYXMgY29t bXVuaWNhdGlvbiBhY3Jvc3MgbXVsdGlwbGUgbmV0d29ya3MsDQo+c2V2ZXJhbCB1c2VyLW9yaWVu dGVkIHNvZnR3YXJlIGFwcGxpY2F0aW9ucyBzdXBwb3J0IGJvdGggU0lQIGFuZCBYTVBQLA0KPmFu ZCBtb3JlIHNvZnR3YXJlIGRldmVsb3BlcnMgaGF2ZSBleHByZXNzZWQgaW50ZXJlc3QgaW4gYnVp bGRpbmcgc3VjaA0KPiJkdWFsLXN0YWNrIiBzb2x1dGlvbnMuICBVbmZvcnR1bmF0ZWx5LCBpdCBp cyBkaWZmaWN1bHQgdG8gcHJvdmlkZSBhDQo+Z29vZCBlbmQtdXNlciBleHBlcmllbmNlIGluIHN1 Y2ggYXBwbGljYXRpb25zIGJlY2F1c2UgU0lQIGFuZCBYTVBQIGFyZQ0KPm5vdCAiYXdhcmUiIG9m IGVhY2ggb3RoZXIuICBGb3IgZXhhbXBsZToNCj4NCj4tIFhNUFAgcHJlc2VuY2UgZG9lcyBub3Qg aW5jbHVkZSBhdmFpbGFiaWxpdHkgc3RhdGVzIHJlbGF0ZWQgdG8gYSBTSVANCj4gIHZvaWNlIGNh bGwgb3IgdmlkZW8gY2FsbCAoZS5nLiwgIm9uIHRoZSBwaG9uZSIpLCB0aHVzIHByZXZlbnRpbmcg YW4NCj4gIGEgZHVhbC1zdGFjayBlbmRwb2ludCBmcm9tIHNob3dpbmcgcHJlc2VuY2UtYmFzZWQg Y29tbXVuaWNhdGlvbiBoaW50cw0KPg0KPi0gVGhlcmUgaXMgbm8gY29ycmVsYXRpb24gYmV0d2Vl biBhbiBYTVBQIElNIHNlc3Npb24gYW5kIGEgU0lQIHZvaWNlDQo+ICBvciB2aWRlbyBzZXNzaW9u LCB0aHVzIHByZXZlbnRpbmcgYSBkdWFsLXN0YWNrIGVuZHBvaW50IGZyb20gcHJvdmlkaW5nDQo+ ICBpbnRlZ3JhdGVkIHVzZXIgaW50ZXJmYWNlcyBhbmQgY29tbXVuaWNhdGlvbnMgaGlzdG9yeQ0K Pg0KPi0gU0lQIGFjY291bnRzIGFuZCBYTVBQIGFjY291bnRzIGFyZSBub3QgZGlyZWN0bHkgY29y cmVsYXRlZCBpbiBjb250YWN0DQo+ICBsaXN0cyBvciB2Q2FyZHMgKGFuZCBub3QgYWxsIGRlcGxv eWVkIHNlcnZpY2VzIHN1cHBvcnQgc3RvcmFnZSBvZiBzdWNoDQo+ICBpbmZvcm1hdGlvbiksIHRo dXMgcHJldmVudGluZyBhIGR1YWwtc3RhY2sgZW5kcG9pbnQgZnJvbSBrbm93aW5nIHRoYXQNCj4g IGEgY29udGFjdCBoYXMgYm90aCBTSVAgYW5kIFhNUFAgY2FwYWJpbGl0aWVzDQo+DQo+QWx0aG91 Z2ggc29tZSBwcm9wcmlldGFyeSBzb2x1dGlvbnMgZXhpc3QgdG8gdGhlIGZvcmVnb2luZyBwcm9i bGVtcywgaXQNCj53b3VsZCBiZSBwcmVmZXJhYmxlIHRvIGRlZmluZSBzdGFuZGFyZGl6ZWQgc29s dXRpb25zIGZvciB0aGUgc2FrZSBvZg0KPmltcHJvdmVkIGludGVyb3BlcmFiaWxpdHkuDQo+DQo+ T2JqZWN0aXZlcw0KPg0KPkJlY2F1c2UgYm90aCBTSVAgYW5kIFhNUFAgYXJlIGVhc2lseSBleHRl bmRlZCB0aHJvdWdoIG5ldyBTSVAgaGVhZGVycw0KPmFuZCBYTVBQIGVsZW1lbnRzLCBpdCBzaG91 bGQgYmUgcG9zc2libGUgdG8gcHJvdmlkZSB0aWdodGVyIGludGVncmF0aW9uDQo+d2l0aGluIGR1 YWwtc3RhY2sgU0lQL1hNUFAgdXNlciBhZ2VudHMgdG8gaW1wcm92ZSB0aGUgdXNlciBleHBlcmll bmNlLg0KPg0KPkFueSBzdWNoIGV4dGVuc2lvbnMgc2hvdWxkIG1lZXQgdGhlIGZvbGxvd2luZyBj cml0ZXJpYToNCj4NCj4tIEJlIGNvbXBsZXRlbHkgb3B0aW9uYWwgYW5kIGJhY2t3YXJkcy1jb21w YXRpYmxlIGZvciBhbGwgZW5kcG9pbnRzDQo+DQo+LSBXb3JrIHdpdGhvdXQgY2hhbmdlcyB0byBk ZXBsb3llZCBpbmZyYXN0cnVjdHVyZSBzdWNoIGFzIGV4aXN0aW5nDQo+ICBTSVAgYW5kIFhNUFAg c2VydmVycywgQjJCVUFzLCBmaXJld2FsbHMsIGV0Yy4NCj4NCj5UaGUgU0lYUEFDIFdHIHdpbGwg ZGVmaW5lIGEgc21hbGwgbnVtYmVyIG9mIFNJUCBhbmQgWE1QUCBleHRlbnNpb25zIHRvDQo+c29s dmUgdGhlIGZvbGxvd2luZyB1c2UgY2FzZXMgaW4gZHVhbC1zdGFjayBlbmRwb2ludHM6DQo+DQo+ LSBJbmNsdWRpbmcgU0lQLWJhc2VkIGF2YWlsYWJpbGl0eSBzdGF0ZXMgaW4gWE1QUCBwcmVzZW5j ZSAobGltaXRlZCB0bw0KPiAgYmFzaWMgcHJlc2VuY2UgYW5kIGF2YWlsYWJpbGl0eSBzdGF0ZXMg b25seSwgbm90IHRoZSBmdWxsIHJhbmdlIG9mDQo+ICBQSURGIGV4dGVuc2lvbnMpDQo+DQo+LSBD b3JyZWxhdGluZyBhbiBYTVBQIElNIHNlc3Npb24gd2l0aCBhIFNJUCB2b2ljZS92aWRlbyBzZXNz aW9uLCBhbmQNCj4gIHZpY2UtdmVyc2ENCj4NCj4tIEFkdmVydGlzaW5nIGEgU0lQIGFjY291bnQg YWRkcmVzcyBvdmVyIFhNUFAgYW5kIGFuIFhNUFAgYWNjb3VudA0KPiAgYWRkcmVzcyBvdmVyIFNJ UA0KPg0KPkFkZGl0aW9uYWwgdXNlIGNhc2VzIGFyZSBvdXQgb2Ygc2NvcGUsIGluY2x1ZGluZyBh bnl0aGluZyByZWxhdGVkIHRvIG9yDQo+cmVxdWlyaW5nIHNlcnZlciBpbnRlZ3JhdGlvbiwgbXVs dGlwYXJ0eSBjb21tdW5pY2F0aW9uLCBTSVAtYmFzZWQgSU0gYW5kDQo+cHJlc2VuY2UsIFhNUFAt YmFzZWQgdm9pY2UgYW5kIHZpZGVvLCBmaWxlIHRyYW5zZmVyLCBnZW5lcmFsaXplZCBzZXJ2aWNl DQo+ZGlzY292ZXJ5IGFuZCBjYXBhYmlsaXRpZXMgZXhjaGFuZ2UsIGZ1bGwgcHJvdG9jb2wgdHJh bnNsYXRpb24gaW4NCj5jb21tdW5pY2F0aW9uIGdhdGV3YXlzLCBzaGFyZWQgY3JlZGVudGlhbHMg YWNyb3NzIGJvdGggU0lQIGFuZCBYTVBQDQo+YWNjb3VudHMsIHJpY2ggcHJlc2VuY2UgZXh0ZW5z aW9ucyBmb3IgZmVhdHVyZXMgc3VjaCBhcyBnZW9sb2NhdGlvbiwNCj5ldGMuIEFsdGhvdWdoIHN1 Y2ggdG9waWNzIGFyZSBpbXBvcnRhbnQgYW5kIGludGVyZXN0aW5nLCB0aGV5IGFyZSBvdXQgb2YN Cj5zY29wZSBmb3IgdGhpcyBncm91cC4NCj4NCj5Ib3dldmVyLCBpbiBhZGRpdGlvbiB0byB0aGUg cHJvdG9jb2wgZXh0ZW5zaW9ucyBleHBsaWNpdGx5IG1lbnRpb25lZA0KPmFib3ZlLCB0aGUgZ3Jv dXAgbWF5IGFsc28gZGVmaW5lIGJlc3QgcHJhY3RpY2VzIHJlbGF0ZWQgdG8gdGhlDQo+aW1wbGVt ZW50YXRpb24gYW5kIGRlcGxveW1lbnQgb2YgZHVhbC1zdGFjayBTSVAvWE1QUCBlbmRwb2ludHMu DQo+DQo+RGVsaXZlcmFibGVzDQo+DQo+LSBVc2UgY2FzZXMgYW5kIHByb3RvY29sIHJlcXVpcmVt ZW50cw0KPg0KPi0gWE1QUCBwcmVzZW5jZSBleHRlbnNpb24gZm9yIFNJUC1iYXNlZCBhdmFpbGFi aWxpdHkgc3RhdGVzDQo+DQo+LSBNZWRpYSBzZXNzaW9uIGNvcnJlbGF0aW9uIGV4dGVuc2lvbnMg Zm9yIFNJUCBhbmQgWE1QUA0KPg0KPi0gQ29udGFjdCBhZGRyZXNzIGFkdmVydGlzZW1lbnQgZXh0 ZW5zaW9ucyBmb3IgU0lQIGFuZCBYTVBQDQo+DQo+LSBCZXN0IHByYWN0aWNlcyBmb3IgaW1wbGVt ZW50YXRpb24gYW5kIGRlcGxveW1lbnQgb2YgZHVhbC1zdGFjaw0KPiAgZW5kcG9pbnRzDQo+DQo+ TWlsZXN0b25lcw0KPg0KPkZlYiAyMDExICBTdWJtaXQgdXNlIGNhc2VzIGFuZCBwcm90b2NvbCBy ZXF1aXJlbWVudHMgZG9jdW1lbnQgdG8gSUVTRw0KPihJbmZvcm1hdGlvbmFsKQ0KPg0KPk9jdCAy MDExICBTdWJtaXQgWE1QUCBwcmVzZW5jZSBleHRlbnNpb24gZG9jdW1lbnQgdG8gSUVTRyAoU3Rh bmRhcmRzDQo+VHJhY2spDQo+DQo+T2N0IDIwMTEgIFN1Ym1pdCBtZWRpYSBzZXNzaW9uIGNvcnJl bGF0aW9uIGV4dGVuc2lvbnMgZG9jdW1lbnQgdG8gSUVTRw0KPihTdGFuZGFyZHMgVHJhY2spDQo+ DQo+T2N0IDIwMTEgIFN1Ym1pdCBjb250YWN0IGFkZHJlc3MgYWR2ZXJ0aXNlbWVudCBleHRlbnNp b24gZG9jdW1lbnQgdG8NCj5JRVNHIChTdGFuZGFyZHMgVHJhY2spDQo+DQo+T2N0IDIwMTEgIFN1 Ym1pdCBiZXN0IHByYWN0aWNlcyBkb2N1bWVudCB0byBJRVNHIChJbmZvcm1hdGlvbmFsKQ0KPg0K DQo= From john.elwell@siemens-enterprise.com Tue Feb 1 23:44:51 2011 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2842B3A6E88 for ; Tue, 1 Feb 2011 23:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbDnQq6UTpwK for ; Tue, 1 Feb 2011 23:44:50 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E50763A6CBE for ; Tue, 1 Feb 2011 23:44:49 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3238393; Wed, 2 Feb 2011 08:48:07 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 548BB1EB82AB; Wed, 2 Feb 2011 08:48:07 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 2 Feb 2011 08:48:07 +0100 From: "Elwell, John" To: "Markus.Isomaki@nokia.com" , "Simo.Veikkolainen@nokia.com" , "sixpac@ietf.org" Date: Wed, 2 Feb 2011 08:48:06 +0100 Thread-Topic: Resolving SIP/XMPP URIs Thread-Index: AQHLwgeGeNM0i3/v7kqPya3/zXRKm5Pt1IaA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sixpac] Resolving SIP/XMPP URIs X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 07:44:51 -0000 I see now, this was meant to be a requirement to obtain the XMPP address WI= THOUT establishing a SIP call. If a SIP call were to be established, that w= ould be covered by REQ-2 (although expressed slightly differently there). So the question is whether, without making a SIP call, there should be a re= quirement to be able to discover the XMPP address. I don't have a strong op= inion, but it certainly sounds reasonable to require this - I could check y= our presence status or send you an IM without calling you. Concerning the solution space, OPTIONS might indeed be one method. For exam= ple, if Call-Info were used to exchange the address during a call, it could= also be exchanged in OPTIONS. There is little else, unless we have an even= t package, which seems unnecessarily complex. John > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 > Sent: 01 February 2011 12:00 > To: Elwell, John; Simo.Veikkolainen@nokia.com; sixpac@ietf.org > Subject: Resolving SIP/XMPP URIs >=20 > Hi, >=20 > John Elwell wrote: > > > >5. "REQ-4: It must be possible for a user, who only knows another > >user's > > SIP URI, to learn the other user's XMPP URI." > >Is there a particular reason this is asymmetrical? Should=20 > there also be > >a requirement for a user who knows another user's XMPP URI=20 > to learn that > >user's SIP URI? > > >=20 > From requirements and user experience perspective this should=20 > be symmetric, so I would agree adding that to the requirements. >=20 > The actual protocol realization may be more challenging. In=20 > the SIXPAC "model" presence information is exchanged via=20 > XMPP. So, if a SIXPAC client knows an XMPP address, it can=20 > conveniently use presence to learn about the corresponding=20 > SIP address (using the envisioned presence data extensions).=20 > But if the SIXPAC client knows a SIP address to start with,=20 > what would be preferred way for learning the corresponding=20 > XMPP address? Would SIP OPTIONS be a good approach? That's=20 > the only realistically deployable method that I can think of.=20 > Can we assume OPTIONS would work at least to a reasonable=20 > extent between SIP UAs in current SIP deployments? (On paper=20 > it does, but unfortunately we always need to ask this=20 > question due to the deployment realities...) >=20 > Markus > = From emcho@sip-communicator.org Wed Feb 2 00:31:39 2011 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46E73A6AF0 for ; Wed, 2 Feb 2011 00:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLrrE27YCFgB for ; Wed, 2 Feb 2011 00:31:38 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A3F7E3A6965 for ; Wed, 2 Feb 2011 00:31:37 -0800 (PST) Received: by ewy8 with SMTP id 8so4002986ewy.31 for ; Wed, 02 Feb 2011 00:34:56 -0800 (PST) Received: by 10.213.33.17 with SMTP id f17mr11422750ebd.6.1296635695933; Wed, 02 Feb 2011 00:34:55 -0800 (PST) Received: from porcinet.local (87-126-226-239.btc-net.bg [87.126.226.239]) by mx.google.com with ESMTPS id t50sm18012634eeh.18.2011.02.02.00.34.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 00:34:54 -0800 (PST) Message-ID: <4D49172B.9050309@sip-communicator.org> Date: Wed, 02 Feb 2011 10:34:51 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Elwell, John" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sixpac@ietf.org" Subject: Re: [sixpac] Resolving SIP/XMPP URIs X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 08:31:40 -0000 Hey folks, =D0=9D=D0=B0 02.02.11 09:48, Elwell, John =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0= =B0: > I see now, this was meant to be a requirement to obtain the XMPP > address WITHOUT establishing a SIP call. If a SIP call were to be > established, that would be covered by REQ-2 (although expressed > slightly differently there). >=20 > So the question is whether, without making a SIP call, there should > be a requirement to be able to discover the XMPP address. I don't > have a strong opinion, but it certainly sounds reasonable to require > this - I could check your presence status or send you an IM without > calling you. Retrieving an XMPP URI from a SIP one _without_ a previous call seems somewhat exotic to me. I'd therefore say that allowing for OPTIONS the same headers that would otherwise carry XMPP URIs during call would be more than enough, and so be it if this doesn't always work. Cheers, Emil > Concerning the solution space, OPTIONS might indeed be one method. > For example, if Call-Info were used to exchange the address during a > call, it could also be exchanged in OPTIONS. There is little else, > unless we have an event package, which seems unnecessarily complex. >=20 > John >=20 >> -----Original Message----- From: Markus.Isomaki@nokia.com >> [mailto:Markus.Isomaki@nokia.com] Sent: 01 February 2011 12:00 To: >> Elwell, John; Simo.Veikkolainen@nokia.com; sixpac@ietf.org Subject: >> Resolving SIP/XMPP URIs >>=20 >> Hi, >>=20 >> John Elwell wrote: >>>=20 >>> 5. "REQ-4: It must be possible for a user, who only knows >>> another user's SIP URI, to learn the other user's XMPP URI." Is >>> there a particular reason this is asymmetrical? Should >> there also be >>> a requirement for a user who knows another user's XMPP URI >> to learn that >>> user's SIP URI? >>>=20 >>=20 >> From requirements and user experience perspective this should be >> symmetric, so I would agree adding that to the requirements. >>=20 >> The actual protocol realization may be more challenging. In the >> SIXPAC "model" presence information is exchanged via XMPP. So, if a >> SIXPAC client knows an XMPP address, it can conveniently use >> presence to learn about the corresponding SIP address (using the >> envisioned presence data extensions). But if the SIXPAC client >> knows a SIP address to start with, what would be preferred way for >> learning the corresponding XMPP address? Would SIP OPTIONS be a >> good approach? That's the only realistically deployable method that >> I can think of. Can we assume OPTIONS would work at least to a >> reasonable extent between SIP UAs in current SIP deployments? (On >> paper it does, but unfortunately we always need to ask this=20 >> question due to the deployment realities...) >>=20 >> Markus >>=20 > _______________________________________________ sixpac mailing list=20 > sixpac@ietf.org https://www.ietf.org/mailman/listinfo/sixpac >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France SIP Communicator emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 http://sip-communicator.org FAX: +33.1.77.62.47.31 From emcho@sip-communicator.org Wed Feb 2 00:38:25 2011 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BAB23A6B75 for ; Wed, 2 Feb 2011 00:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T33FqbYh1VVc for ; Wed, 2 Feb 2011 00:38:24 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 996FD3A7123 for ; Wed, 2 Feb 2011 00:38:23 -0800 (PST) Received: by ewy8 with SMTP id 8so4005094ewy.31 for ; Wed, 02 Feb 2011 00:41:42 -0800 (PST) Received: by 10.14.122.79 with SMTP id s55mr9460973eeh.32.1296636101977; Wed, 02 Feb 2011 00:41:41 -0800 (PST) Received: from porcinet.local (87-126-226-239.btc-net.bg [87.126.226.239]) by mx.google.com with ESMTPS id t5sm18011531eeh.14.2011.02.02.00.41.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 00:41:41 -0800 (PST) Message-ID: <4D4918C2.6090004@sip-communicator.org> Date: Wed, 02 Feb 2011 10:41:38 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <4CDB9E64.6070704@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sixpac@ietf.org Subject: Re: [sixpac] Chartering... X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 08:38:25 -0000 =D0=9D=D0=B0 01.02.11 14:42, Markus.Isomaki@nokia.com =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0: > 2. The client configuration part was dropped. Is that OK? >=20 > There was not really a common understanding on what the group would > do, so the text was prone to misunderstandings.=20 Probably, yes. > I don't think > anyone's intention was to design something completely new just for > SIXPAC clients. Nope, indeed not. I am probably going to bring up the issue again once we start designing the actual spec and I am quite confident that a few lines recommending the use of standard SIP/XMPP discovery mechanisms with SIXPAC would be just fine for everyone and compliant with the charte= r. Cheers, Emil > 3. Correlation and SIP deployment reality (B2BUAs, SBCs, ...) >=20 > Some people think that the "correlation between an XMPP IM session > and a SIP voice or video session" is only going to work in "standards > compliant" SIP networks, which may not exist due to the excessive > deployment of SBCs and other types of B2BUA, who strip out or > override end-to-end data between SIP UAs. This is certainly a risk, > but fortunately I think in most cases the correlation is just an > optimization/nice-to-have feature, and even if it fails on some or > even most sessions, we will not ruin the user experience (it will be > anyway better with SIXPAC than completely isolated SIP and XMPP > clients). In the end I think we should here only worry about user > experience, not get into the philosophical discussion about SBCs. We > should also make sure our correlation method is > straight-to-the-purpose (SIXPAC) and not some kind of generic > framework a la session id or splices or something like that, that > will open doors to all kinds of conspiracy theories what it can also > be used for. >=20 > So, from my perspective the charter text is good (enough) as it is > now, and we only need to worry about point 1 (track record so far has > not been that impressive due to various reasons). >=20 > Any comments? Have I missed other issues/ratholes about the charter? >=20 > Markus >=20 >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>=20 =3D >> SIXPAC (SIP Integration with XMPP in Presence Aware Clients)=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>=20 =3D >>=20 >> Problem Statement >>=20 >> Both the Session Initiation Protocol (SIP) and the Extensible >> Messaging and Presence Protocol (XMPP) are widely deployed >> technologies for real- time communication over the Internet. In >> order to offer a complete suite of features as well as >> communication across multiple networks, several user-oriented >> software applications support both SIP and XMPP, and more software >> developers have expressed interest in building such "dual-stack" >> solutions. Unfortunately, it is difficult to provide a good >> end-user experience in such applications because SIP and XMPP are=20 >> not "aware" of each other. For example: >>=20 >> - XMPP presence does not include availability states related to a >> SIP voice call or video call (e.g., "on the phone"), thus >> preventing an a dual-stack endpoint from showing presence-based >> communication hints >>=20 >> - There is no correlation between an XMPP IM session and a SIP >> voice or video session, thus preventing a dual-stack endpoint from >> providing integrated user interfaces and communications history >>=20 >> - SIP accounts and XMPP accounts are not directly correlated in >> contact lists or vCards (and not all deployed services support >> storage of such information), thus preventing a dual-stack endpoint >> from knowing that a contact has both SIP and XMPP capabilities >>=20 >> Although some proprietary solutions exist to the foregoing >> problems, it would be preferable to define standardized solutions >> for the sake of improved interoperability. >>=20 >> Objectives >>=20 >> Because both SIP and XMPP are easily extended through new SIP >> headers and XMPP elements, it should be possible to provide tighter >> integration within dual-stack SIP/XMPP user agents to improve the >> user experience. >>=20 >> Any such extensions should meet the following criteria: >>=20 >> - Be completely optional and backwards-compatible for all >> endpoints >>=20 >> - Work without changes to deployed infrastructure such as existing=20 >> SIP and XMPP servers, B2BUAs, firewalls, etc. >>=20 >> The SIXPAC WG will define a small number of SIP and XMPP extensions >> to solve the following use cases in dual-stack endpoints: >>=20 >> - Including SIP-based availability states in XMPP presence (limited >> to basic presence and availability states only, not the full range >> of PIDF extensions) >>=20 >> - Correlating an XMPP IM session with a SIP voice/video session, >> and vice-versa >>=20 >> - Advertising a SIP account address over XMPP and an XMPP account=20 >> address over SIP >>=20 >> Additional use cases are out of scope, including anything related >> to or requiring server integration, multiparty communication, >> SIP-based IM and presence, XMPP-based voice and video, file >> transfer, generalized service discovery and capabilities exchange, >> full protocol translation in communication gateways, shared >> credentials across both SIP and XMPP accounts, rich presence >> extensions for features such as geolocation, etc. Although such >> topics are important and interesting, they are out of scope for >> this group. >>=20 >> However, in addition to the protocol extensions explicitly >> mentioned above, the group may also define best practices related >> to the implementation and deployment of dual-stack SIP/XMPP >> endpoints. >>=20 >> Deliverables >>=20 >> - Use cases and protocol requirements >>=20 >> - XMPP presence extension for SIP-based availability states >>=20 >> - Media session correlation extensions for SIP and XMPP >>=20 >> - Contact address advertisement extensions for SIP and XMPP >>=20 >> - Best practices for implementation and deployment of dual-stack=20 >> endpoints >>=20 >> Milestones >>=20 >> Feb 2011 Submit use cases and protocol requirements document to >> IESG (Informational) >>=20 >> Oct 2011 Submit XMPP presence extension document to IESG >> (Standards Track) >>=20 >> Oct 2011 Submit media session correlation extensions document to >> IESG (Standards Track) >>=20 >> Oct 2011 Submit contact address advertisement extension document >> to IESG (Standards Track) >>=20 >> Oct 2011 Submit best practices document to IESG (Informational) >>=20 >=20 > _______________________________________________ sixpac mailing list=20 > sixpac@ietf.org https://www.ietf.org/mailman/listinfo/sixpac >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France SIP Communicator emcho@sip-communicator.org PHONE: +33.1.77.62.43.30 http://sip-communicator.org FAX: +33.1.77.62.47.31 From Simo.Veikkolainen@nokia.com Thu Feb 3 05:37:23 2011 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB3A3A6919 for ; Thu, 3 Feb 2011 05:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3wJ8jaNXzOZ for ; Thu, 3 Feb 2011 05:37:21 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id C90253A68F8 for ; Thu, 3 Feb 2011 05:37:21 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p13DeP2r025327; Thu, 3 Feb 2011 15:40:43 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 15:40:35 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 3 Feb 2011 14:40:34 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Thu, 3 Feb 2011 14:40:29 +0100 From: To: , Thread-Topic: [sixpac] Resolving SIP/XMPP URIs Thread-Index: AQHLwrQcNz3WGAhyB0y3L8KdQqtgZZPvyYZg Date: Thu, 3 Feb 2011 13:40:27 +0000 Message-ID: References: <4D49172B.9050309@sip-communicator.org> In-Reply-To: <4D49172B.9050309@sip-communicator.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2011 13:40:35.0474 (UTC) FILETIME=[EF779F20:01CBC3A7] X-Nokia-AV: Clean Cc: sixpac@ietf.org Subject: Re: [sixpac] Resolving SIP/XMPP URIs X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 13:37:23 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBleHQgRW1pbCBJdm92IFttYWls dG86ZW1jaG9Ac2lwLWNvbW11bmljYXRvci5vcmddDQo+IFNlbnQ6IDAyIEZlYnJ1YXJ5LCAyMDEx IDEwOjM1DQo+IFRvOiBFbHdlbGwsIEpvaG4NCj4gQ2M6IElzb21ha2kgTWFya3VzIChOb2tpYS1D SUMvRXNwb28pOyBWZWlra29sYWluZW4gU2ltbyAoTm9raWEtDQo+IE1TL0hlbHNpbmtpKTsgc2l4 cGFjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2l4cGFjXSBSZXNvbHZpbmcgU0lQL1hNUFAg VVJJcw0KPiANCj4gSGV5IGZvbGtzLA0KPiANCj4g0J3QsCAwMi4wMi4xMSAwOTo0OCwgRWx3ZWxs LCBKb2huINC90LDQv9C40YHQsDoNCj4gPiBJIHNlZSBub3csIHRoaXMgd2FzIG1lYW50IHRvIGJl IGEgcmVxdWlyZW1lbnQgdG8gb2J0YWluIHRoZSBYTVBQDQo+ID4gYWRkcmVzcyBXSVRIT1VUIGVz dGFibGlzaGluZyBhIFNJUCBjYWxsLiBJZiBhIFNJUCBjYWxsIHdlcmUgdG8gYmUNCj4gPiBlc3Rh Ymxpc2hlZCwgdGhhdCB3b3VsZCBiZSBjb3ZlcmVkIGJ5IFJFUS0yIChhbHRob3VnaCBleHByZXNz ZWQNCj4gPiBzbGlnaHRseSBkaWZmZXJlbnRseSB0aGVyZSkuDQo+ID4NCj4gPiBTbyB0aGUgcXVl c3Rpb24gaXMgd2hldGhlciwgd2l0aG91dCBtYWtpbmcgYSBTSVAgY2FsbCwgdGhlcmUgc2hvdWxk DQo+ID4gYmUgYSByZXF1aXJlbWVudCB0byBiZSBhYmxlIHRvIGRpc2NvdmVyIHRoZSBYTVBQIGFk ZHJlc3MuIEkgZG9uJ3QNCj4gPiBoYXZlIGEgc3Ryb25nIG9waW5pb24sIGJ1dCBpdCBjZXJ0YWlu bHkgc291bmRzIHJlYXNvbmFibGUgdG8gcmVxdWlyZQ0KPiA+IHRoaXMgLSBJIGNvdWxkIGNoZWNr IHlvdXIgcHJlc2VuY2Ugc3RhdHVzIG9yIHNlbmQgeW91IGFuIElNIHdpdGhvdXQNCj4gPiBjYWxs aW5nIHlvdS4NCj4gDQo+IFJldHJpZXZpbmcgYW4gWE1QUCBVUkkgZnJvbSBhIFNJUCBvbmUgX3dp dGhvdXRfIGEgcHJldmlvdXMgY2FsbCBzZWVtcw0KPiBzb21ld2hhdCBleG90aWMgdG8gbWUuIEkn ZCB0aGVyZWZvcmUgc2F5IHRoYXQgYWxsb3dpbmcgZm9yIE9QVElPTlMgdGhlDQo+IHNhbWUgaGVh ZGVycyB0aGF0IHdvdWxkIG90aGVyd2lzZSBjYXJyeSBYTVBQIFVSSXMgZHVyaW5nIGNhbGwgd291 bGQgYmUNCj4gbW9yZSB0aGFuIGVub3VnaCwgYW5kIHNvIGJlIGl0IGlmIHRoaXMgZG9lc24ndCBh bHdheXMgd29yay4NCg0KSSB3b3VsZCBhbHNvIGFzc3VtZSB0aGF0IHRoZSB1c3VhbCBwYXR0ZXJu IGlzIHRoYXQgeW91IHN1YnNjcmliZSB0byBYTVBQIHByZXNlbmNlIGFuZCBsZWFybiB0aGUgU0lQ IGFkZHJlc3MgdGhhdCB3YXkuDQoNCkJ1dCwgYXMgbG9uZyBhcyB0aGUgcmVxdWlyZW1lbnQgaXMg Y29uY2VybmVkLCB3b3VsZCBldmVyeW9uZSBiZSBoYXBweSB3aXRoIHRoaXMgdGV4dDoNCg0KICAg ICAgICAgSXQgbXVzdCBiZSBwb3NzaWJsZSBmb3IgYSB1c2VyLCB3aG8gb25seSBrbm93cyBhbm90 aGVyDQogICAgICAgICB1c2Vy4oCZcyBTSVAgVVJJLCB0byBsZWFybiB0aGUgb3RoZXIgdXNlcuKA mXMgWE1QUCBVUkksIGFuZA0KCSAgIHZpY2UgdmVyc2EuDQoNCg0KUmVnYXJkcywNClNpbW8NCg0K PiBDaGVlcnMsDQo+IEVtaWwNCj4gDQo+ID4gQ29uY2VybmluZyB0aGUgc29sdXRpb24gc3BhY2Us IE9QVElPTlMgbWlnaHQgaW5kZWVkIGJlIG9uZSBtZXRob2QuDQo+ID4gRm9yIGV4YW1wbGUsIGlm IENhbGwtSW5mbyB3ZXJlIHVzZWQgdG8gZXhjaGFuZ2UgdGhlIGFkZHJlc3MgZHVyaW5nIGENCj4g PiBjYWxsLCBpdCBjb3VsZCBhbHNvIGJlIGV4Y2hhbmdlZCBpbiBPUFRJT05TLiBUaGVyZSBpcyBs aXR0bGUgZWxzZSwNCj4gPiB1bmxlc3Mgd2UgaGF2ZSBhbiBldmVudCBwYWNrYWdlLCB3aGljaCBz ZWVtcyB1bm5lY2Vzc2FyaWx5IGNvbXBsZXguDQo+ID4NCj4gPiBKb2huDQo+ID4NCj4gPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogTWFya3VzLklzb21ha2lAbm9raWEuY29tDQo+ ID4+IFttYWlsdG86TWFya3VzLklzb21ha2lAbm9raWEuY29tXSBTZW50OiAwMSBGZWJydWFyeSAy MDExIDEyOjAwIFRvOg0KPiA+PiBFbHdlbGwsIEpvaG47IFNpbW8uVmVpa2tvbGFpbmVuQG5va2lh LmNvbTsgc2l4cGFjQGlldGYub3JnIFN1YmplY3Q6DQo+ID4+IFJlc29sdmluZyBTSVAvWE1QUCBV UklzDQo+ID4+DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBKb2huIEVsd2VsbCB3cm90ZToNCj4gPj4+ DQo+ID4+PiA1LiAiUkVRLTQ6ICBJdCBtdXN0IGJlIHBvc3NpYmxlIGZvciBhIHVzZXIsIHdobyBv bmx5IGtub3dzDQo+ID4+PiBhbm90aGVyIHVzZXIncyBTSVAgVVJJLCB0byBsZWFybiB0aGUgb3Ro ZXIgdXNlcidzIFhNUFAgVVJJLiIgSXMNCj4gPj4+IHRoZXJlIGEgcGFydGljdWxhciByZWFzb24g dGhpcyBpcyBhc3ltbWV0cmljYWw/IFNob3VsZA0KPiA+PiB0aGVyZSBhbHNvIGJlDQo+ID4+PiBh IHJlcXVpcmVtZW50IGZvciBhIHVzZXIgd2hvIGtub3dzIGFub3RoZXIgdXNlcidzIFhNUFAgVVJJ DQo+ID4+IHRvIGxlYXJuIHRoYXQNCj4gPj4+IHVzZXIncyBTSVAgVVJJPw0KPiA+Pj4NCj4gPj4N Cj4gPj4gRnJvbSByZXF1aXJlbWVudHMgYW5kIHVzZXIgZXhwZXJpZW5jZSBwZXJzcGVjdGl2ZSB0 aGlzIHNob3VsZCBiZQ0KPiA+PiBzeW1tZXRyaWMsIHNvIEkgd291bGQgYWdyZWUgYWRkaW5nIHRo YXQgdG8gdGhlIHJlcXVpcmVtZW50cy4NCj4gPj4NCj4gPj4gVGhlIGFjdHVhbCBwcm90b2NvbCBy ZWFsaXphdGlvbiBtYXkgYmUgbW9yZSBjaGFsbGVuZ2luZy4gSW4gdGhlDQo+ID4+IFNJWFBBQyAi bW9kZWwiIHByZXNlbmNlIGluZm9ybWF0aW9uIGlzIGV4Y2hhbmdlZCB2aWEgWE1QUC4gU28sIGlm IGENCj4gPj4gU0lYUEFDIGNsaWVudCBrbm93cyBhbiBYTVBQIGFkZHJlc3MsIGl0IGNhbiBjb252 ZW5pZW50bHkgdXNlDQo+ID4+IHByZXNlbmNlIHRvIGxlYXJuIGFib3V0IHRoZSBjb3JyZXNwb25k aW5nIFNJUCBhZGRyZXNzICh1c2luZyB0aGUNCj4gPj4gZW52aXNpb25lZCBwcmVzZW5jZSBkYXRh IGV4dGVuc2lvbnMpLiBCdXQgaWYgdGhlIFNJWFBBQyBjbGllbnQNCj4gPj4ga25vd3MgYSBTSVAg YWRkcmVzcyB0byBzdGFydCB3aXRoLCB3aGF0IHdvdWxkIGJlIHByZWZlcnJlZCB3YXkgZm9yDQo+ ID4+IGxlYXJuaW5nIHRoZSBjb3JyZXNwb25kaW5nIFhNUFAgYWRkcmVzcz8gV291bGQgU0lQIE9Q VElPTlMgYmUgYQ0KPiA+PiBnb29kIGFwcHJvYWNoPyBUaGF0J3MgdGhlIG9ubHkgcmVhbGlzdGlj YWxseSBkZXBsb3lhYmxlIG1ldGhvZCB0aGF0DQo+ID4+IEkgY2FuIHRoaW5rIG9mLiBDYW4gd2Ug YXNzdW1lIE9QVElPTlMgd291bGQgd29yayBhdCBsZWFzdCB0byBhDQo+ID4+IHJlYXNvbmFibGUg ZXh0ZW50IGJldHdlZW4gU0lQIFVBcyBpbiBjdXJyZW50IFNJUCBkZXBsb3ltZW50cz8gKE9uDQo+ ID4+IHBhcGVyIGl0IGRvZXMsIGJ1dCB1bmZvcnR1bmF0ZWx5IHdlIGFsd2F5cyBuZWVkIHRvIGFz ayB0aGlzDQo+ID4+IHF1ZXN0aW9uIGR1ZSB0byB0aGUgZGVwbG95bWVudCByZWFsaXRpZXMuLi4p DQo+ID4+DQo+ID4+IE1hcmt1cw0KPiA+Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIHNpeHBhYyBtYWlsaW5nIGxpc3QNCj4gPiBzaXhwYWNAaWV0 Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXhwYWMNCj4gPg0K PiANCj4gLS0NCj4gRW1pbCBJdm92LCBQaC5ELiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA2NzAwMCBTdHJhc2JvdXJnLA0KPiBQcm9qZWN0IExlYWQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEZyYW5jZQ0KPiBTSVAgQ29tbXVuaWNhdG9yDQo+IGVtY2hvQHNpcC1jb21t dW5pY2F0b3Iub3JnICAgICAgICAgICAgICAgICAgICAgUEhPTkU6ICszMy4xLjc3LjYyLjQzLjMw DQo+IGh0dHA6Ly9zaXAtY29tbXVuaWNhdG9yLm9yZyAgICAgICAgICAgICAgICAgICAgRkFYOiAg ICszMy4xLjc3LjYyLjQ3LjMxDQoNCg== From john.elwell@siemens-enterprise.com Thu Feb 3 09:26:52 2011 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2563A6A37 for ; Thu, 3 Feb 2011 09:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.25 X-Spam-Level: X-Spam-Status: No, score=-101.25 tagged_above=-999 required=5 tests=[AWL=-1.101, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50GLr3wpMO28 for ; Thu, 3 Feb 2011 09:26:51 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DA4A83A6A38 for ; Thu, 3 Feb 2011 09:26:50 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3256995; Thu, 3 Feb 2011 18:29:47 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 0F72623F028E; Thu, 3 Feb 2011 18:29:47 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 3 Feb 2011 18:29:46 +0100 From: "Elwell, John" To: "Simo.Veikkolainen@nokia.com" , "emcho@sip-communicator.org" Date: Thu, 3 Feb 2011 18:29:45 +0100 Thread-Topic: [sixpac] Resolving SIP/XMPP URIs Thread-Index: AQHLwrQcNz3WGAhyB0y3L8KdQqtgZZPvyYZggAA/5aA= Message-ID: References: <4D49172B.9050309@sip-communicator.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sixpac@ietf.org" Subject: Re: [sixpac] Resolving SIP/XMPP URIs X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:26:52 -0000 One scenario would be a user who has only a telephone number. That could be= used to make a call to the other user, but it might be preferred to look a= t presence or send an IM first. I agree this is perhaps not a very common situation. When only a telephone = number is available, it tends to be for somebody outside one's organization= , and probably presence / IM would not be available anyway. Perhaps this is just a desirable, not a firm requirement. I will go with th= e majority. John=20 > -----Original Message----- > From: Simo.Veikkolainen@nokia.com=20 > [mailto:Simo.Veikkolainen@nokia.com]=20 > Sent: 03 February 2011 13:40 > To: emcho@sip-communicator.org; Elwell, John > Cc: Markus.Isomaki@nokia.com; sixpac@ietf.org > Subject: RE: [sixpac] Resolving SIP/XMPP URIs >=20 > > -----Original Message----- > > From: ext Emil Ivov [mailto:emcho@sip-communicator.org] > > Sent: 02 February, 2011 10:35 > > To: Elwell, John > > Cc: Isomaki Markus (Nokia-CIC/Espoo); Veikkolainen Simo (Nokia- > > MS/Helsinki); sixpac@ietf.org > > Subject: Re: [sixpac] Resolving SIP/XMPP URIs > >=20 > > Hey folks, > >=20 > > =EE=C1 02.02.11 09:48, Elwell, John =CE=C1=D0=C9=D3=C1: > > > I see now, this was meant to be a requirement to obtain the XMPP > > > address WITHOUT establishing a SIP call. If a SIP call were to be > > > established, that would be covered by REQ-2 (although expressed > > > slightly differently there). > > > > > > So the question is whether, without making a SIP call,=20 > there should > > > be a requirement to be able to discover the XMPP address. I don't > > > have a strong opinion, but it certainly sounds reasonable=20 > to require > > > this - I could check your presence status or send you an=20 > IM without > > > calling you. > >=20 > > Retrieving an XMPP URI from a SIP one _without_ a previous=20 > call seems > > somewhat exotic to me. I'd therefore say that allowing for=20 > OPTIONS the > > same headers that would otherwise carry XMPP URIs during=20 > call would be > > more than enough, and so be it if this doesn't always work. >=20 > I would also assume that the usual pattern is that you=20 > subscribe to XMPP presence and learn the SIP address that way. >=20 > But, as long as the requirement is concerned, would everyone=20 > be happy with this text: >=20 > It must be possible for a user, who only knows another > user's SIP URI, to learn the other user's XMPP URI, and > vice versa. >=20 >=20 > Regards, > Simo >=20 > > Cheers, > > Emil > >=20 > > > Concerning the solution space, OPTIONS might indeed be one method. > > > For example, if Call-Info were used to exchange the=20 > address during a > > > call, it could also be exchanged in OPTIONS. There is little else, > > > unless we have an event package, which seems=20 > unnecessarily complex. > > > > > > John > > > > > >> -----Original Message----- From: Markus.Isomaki@nokia.com > > >> [mailto:Markus.Isomaki@nokia.com] Sent: 01 February 2011=20 > 12:00 To: > > >> Elwell, John; Simo.Veikkolainen@nokia.com;=20 > sixpac@ietf.org Subject: > > >> Resolving SIP/XMPP URIs > > >> > > >> Hi, > > >> > > >> John Elwell wrote: > > >>> > > >>> 5. "REQ-4: It must be possible for a user, who only knows > > >>> another user's SIP URI, to learn the other user's XMPP URI." Is > > >>> there a particular reason this is asymmetrical? Should > > >> there also be > > >>> a requirement for a user who knows another user's XMPP URI > > >> to learn that > > >>> user's SIP URI? > > >>> > > >> > > >> From requirements and user experience perspective this should be > > >> symmetric, so I would agree adding that to the requirements. > > >> > > >> The actual protocol realization may be more challenging. In the > > >> SIXPAC "model" presence information is exchanged via=20 > XMPP. So, if a > > >> SIXPAC client knows an XMPP address, it can conveniently use > > >> presence to learn about the corresponding SIP address (using the > > >> envisioned presence data extensions). But if the SIXPAC client > > >> knows a SIP address to start with, what would be=20 > preferred way for > > >> learning the corresponding XMPP address? Would SIP OPTIONS be a > > >> good approach? That's the only realistically deployable=20 > method that > > >> I can think of. Can we assume OPTIONS would work at least to a > > >> reasonable extent between SIP UAs in current SIP deployments? (On > > >> paper it does, but unfortunately we always need to ask this > > >> question due to the deployment realities...) > > >> > > >> Markus > > >> > > > _______________________________________________ sixpac=20 > mailing list > > > sixpac@ietf.org https://www.ietf.org/mailman/listinfo/sixpac > > > > >=20 > > -- > > Emil Ivov, Ph.D. 67000 Strasbourg, > > Project Lead France > > SIP Communicator > > emcho@sip-communicator.org PHONE:=20 > +33.1.77.62.43.30 > > http://sip-communicator.org FAX: =20 > +33.1.77.62.47.31 >=20 > = From gunnar.hellstrom@omnitor.se Tue Feb 8 11:16:44 2011 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DBAF3A672E for ; Tue, 8 Feb 2011 11:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyPRaE7CUwp1 for ; Tue, 8 Feb 2011 11:16:43 -0800 (PST) Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 235603A682C for ; Tue, 8 Feb 2011 11:16:21 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for ; Tue, 8 Feb 2011 20:16:18 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id 059CF3A17A for ; Tue, 8 Feb 2011 20:16:18 +0100 (CET) Message-ID: <4D519681.4070404@omnitor.se> Date: Tue, 08 Feb 2011 20:16:17 +0100 From: =?UTF-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sixpac References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [sixpac] Capability and preference expression and interrogation X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:16:44 -0000 I think it is important that the capability to do XMPP messaging with a SIP endpoint is expressed in regular SIP ways, so that capability checking for that function even can be done before a session is initiated, and also during session initiation. E.g. the functionality should have the possibility to influence the outcome of caller preferences - callee capabilities interrogations (RFC 3840, RFC 3841 ). It seems to me that that is easily achieved, but that is not the issue at the moment, when collecting requirements. I cannot find exactly that need described in the current requirements, so I suggest to add a requirement like this: REQ-x: The capability or preference to initiate and accept XMPP messages must be possible to express and interrogate by the standard mechanisms for such functions in SIP for caller preferences and callee capabilities. ( RFC 3840, RFC 3841 etc.) Use case: Alice want to call Bob to have his view of some new poems she has written. She has a SIP phone with XMPP chat addition. She makes sure that her phone expresses a preference for audio and text messaging in the call. Bob has two phones registered on his address. One only with audio functionality, the other with both audio and text messaging. The SIP server can match the Alice's preferences with the capabilities of Bob's phones, and direct the call to the device where he can receive and read the poems and comment them in their voice conversation. --- I am not sure if similar standardised features are available for XMPP so that it is relevant to express the symmetric requirements on the XMPP side. Gunnar ______________________________________________________________________________-- Simo.Veikkolainen@nokia.com skrev 2011-01-26 21:20: > You're right, we should get some discussion going on. > > I have just uploaded a new version of draft-veikkolainen-sip-xmpp-coex-reqs, which can be found at http://www.ietf.org/internet-drafts/draft-veikkolainen-sip-xmpp-coex-reqs-02.txt > > The changes in this version address the comments made by Peter Musgrave (mainly clarifications): > > In REQ-1: “SIP contact” changed to “SIP address” > > In REQ-3: "It must be possible to include SIP real-time media related contact and status in XMPP presence information." changed to "It must be possible to include SIP address and status information in XMPP presence." > > And a couple of typos. > > One further comment made by Peter might merit a bit more discussion, namely saying something about cases where two SIP devices are registered to the same AOR and two XMPP clients are logged in. This is related to the discussion we had an correlation, and whether or not it should be mentioned in the charter or not. > > Opinions on this would be helpful. > > Also, please take a fresh look at the draft and express your opinions on whether the approach in general makes sense, do you agree with the use cases and requirements, is something missing etc. > > Thanks > Simo > > > -----Original Message----- > From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 26 January, 2011 22:05 > To: Veikkolainen Simo (Nokia-MS/Helsinki) > Cc: Isomaki Markus (Nokia-CIC/Espoo) > Subject: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02 > > > A new version of I-D, draft-veikkolainen-sip-xmpp-coex-reqs-02.txt has been successfully submitted by Simo Veikkolainen and posted to the IETF repository. > > Filename: draft-veikkolainen-sip-xmpp-coex-reqs > Revision: 02 > Title: Requirements and Use Cases for Combining SIP Based Real-time Media Sessions With XMPP Based Instant Messaging and Presence Service. > Creation_date: 2011-01-26 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > This memo defines use cases and requirements for combining Session > Initiation Protocol (SIP) based real-time media sessions with > Extensible Messaging and Presence Protocol (XMPP) based instant > messaging and presence services in a seamless manner. > > > > The IETF Secretariat. > > > _______________________________________________ > sixpac mailing list > sixpac@ietf.org > https://www.ietf.org/mailman/listinfo/sixpac From john.elwell@siemens-enterprise.com Thu Feb 10 03:12:54 2011 Return-Path: X-Original-To: sixpac@core3.amsl.com Delivered-To: sixpac@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224333A6985 for ; Thu, 10 Feb 2011 03:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaMldbvhDscg for ; Thu, 10 Feb 2011 03:12:53 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 961C73A6965 for ; Thu, 10 Feb 2011 03:12:52 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3344575; Thu, 10 Feb 2011 12:13:03 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 4C50B1EB82AE; Thu, 10 Feb 2011 12:13:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 10 Feb 2011 12:13:03 +0100 From: "Elwell, John" To: "Markus.Isomaki@nokia.com" , "Simo.Veikkolainen@nokia.com" , "sixpac@ietf.org" Date: Thu, 10 Feb 2011 12:13:02 +0100 Thread-Topic: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02 Thread-Index: AQHLvZTBMsVG7EQwQ06Q+aXi3KtO9ZPjrp/wgADIKnCACBBjAIALB6lA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02 X-BeenThere: sixpac@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 11:12:54 -0000 I took a look again (sorry for the delay). It looks like a good basis. I ca= n imagine the biggest discussion will be on the subject of the SIP session = identifier. We need something that stands a reasonable chance of getting th= rough SIP B2BUAs. I am not sure one of the examples is correct: "He picks up Alice's contact information that Alice sent to him in a message stanza, and issues a SIP INVITE request to that URI." The request line that follows is: "INVITE sip:alice@example.net SIP/2.0" This contains Alice's AOR, not the contact advertised in XMPP. Also in the response, I would expect to see Alice's gruu in the Contact hea= der field. John > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 > Sent: 01 February 2011 11:37 > To: Elwell, John; Simo.Veikkolainen@nokia.com; sixpac@ietf.org > Subject: RE: [sixpac] FW: New Version Notification for=20 > draft-veikkolainen-sip-xmpp-coex-reqs-02 >=20 > Hi John, >=20 > John Elwell wrote: > >The requirements look reasonable. I would like to see some solution > >proposals, to help gauge whether the requirements are reasonable and > >sufficient. >=20 > For one approach you can take a look at an old draft we did: > http://tools.ietf.org/id/draft-veikkolainen-sip-voip-xmpp-im-01.txt >=20 > For protocol proposals and operation, see Chapter 5 onwards. >=20 > Please comment if you think that track would be reasonable to=20 > meet some/most of the requirements. >=20 > Markus >=20 >=20 > >-----Original Message----- > >From: sixpac-bounces@ietf.org=20 > [mailto:sixpac-bounces@ietf.org] On Behalf > >Of ext Elwell, John > >Sent: 27 January, 2011 12:09 > >To: Veikkolainen Simo (Nokia-MS/Helsinki); sixpac@ietf.org > >Subject: Re: [sixpac] FW: New Version Notification for draft- > >veikkolainen-sip-xmpp-coex-reqs-02 > > > >The requirements look reasonable. I would like to see some solution > >proposals, to help gauge whether the requirements are reasonable and > >sufficient. > > > >Just a few minor comments: > >1. "Offering overlapping services (e.g. > > presence) via both SIP and XMPP is out of scope of this document." > >The term "overlapping" is not entirely clear on its own. Perhaps it > >might be better to say: > >"Offering the same service (e.g., presence) via both SIP and=20 > XMPP....". > > > >2. "We assume that the user initially only needs to know the contact > > address of the other user in one protocol space. The=20 > contact address > > for the other protocol must be learned by some means." > >The second sentence doesn't make it clear that this=20 > discovery is within > >the scope of SIXPAC. I would suggest: > >"Discovering the contact address for the other protocol is within the > >scope of this work." > > > >3. "When > > an integrated endpoint communicates with a separated=20 > endpoint, normal > > SIP and XMPP procedures apply and no extensions defined=20 > in this memo > > are used." > >In fact the integrated endpoint might attempt to use SIXPAC=20 > extensions, > >but would fall back to using basic SIP/XMPP. Also "this=20 > memo" does not > >define extensions, only requirements. > >I would suggest: > >"When an integrated endpoint communicates with a separated endpoint, > >they should fall back to using normal SIP and XMPP procedures." > > > >4. " A user who has obtained another user's SIP URI is able=20 > to discover > > the other user's XMPP URI so that she can send the=20 > other user XMPP > > IM or subscribe to the other user's presence, or just=20 > populate her > > address book for futher use. The user is able to do=20 > this without > > bothering the other user, provided the other user has pre- > > authorized the operation." > >Should this be a 4th bullet, rather than an ordinary=20 > paragraph extending > >the 3rd bullet? > > > >5. "REQ-4: It must be possible for a user, who only knows another > >user's > > SIP URI, to learn the other user's XMPP URI." > >Is there a particular reason this is asymmetrical? Should=20 > there also be > >a requirement for a user who knows another user's XMPP URI=20 > to learn that > >user's SIP URI? > > > >John > > > >> -----Original Message----- > >> From: sixpac-bounces@ietf.org > >> [mailto:sixpac-bounces@ietf.org] On Behalf Of > >> Simo.Veikkolainen@nokia.com > >> Sent: 26 January 2011 20:20 > >> To: sixpac@ietf.org > >> Subject: [sixpac] FW: New Version Notification for > >> draft-veikkolainen-sip-xmpp-coex-reqs-02 > >> > >> You're right, we should get some discussion going on. > >> > >> I have just uploaded a new version of > >> draft-veikkolainen-sip-xmpp-coex-reqs, which can be found at > >> http://www.ietf.org/internet-drafts/draft-veikkolainen-sip-xmp > >> p-coex-reqs-02.txt > >> > >> The changes in this version address the comments made by > >> Peter Musgrave (mainly clarifications): > >> > >> In REQ-1: "SIP contact" changed to "SIP address" > >> > >> In REQ-3: "It must be possible to include SIP real-time media > >> related contact and status in XMPP presence information." > >> changed to "It must be possible to include SIP address and > >> status information in XMPP presence." > >> > >> And a couple of typos. > >> > >> One further comment made by Peter might merit a bit more > >> discussion, namely saying something about cases where two SIP > >> devices are registered to the same AOR and two XMPP clients > >> are logged in. This is related to the discussion we had an > >> correlation, and whether or not it should be mentioned in the > >> charter or not. > >> > >> Opinions on this would be helpful. > >> > >> Also, please take a fresh look at the draft and express your > >> opinions on whether the approach in general makes sense, do > >> you agree with the use cases and requirements, is something > >> missing etc. > >> > >> Thanks > >> Simo > >> > >> > >> -----Original Message----- > >> From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > >> Sent: 26 January, 2011 22:05 > >> To: Veikkolainen Simo (Nokia-MS/Helsinki) > >> Cc: Isomaki Markus (Nokia-CIC/Espoo) > >> Subject: New Version Notification for > >> draft-veikkolainen-sip-xmpp-coex-reqs-02 > >> > >> > >> A new version of I-D, > >> draft-veikkolainen-sip-xmpp-coex-reqs-02.txt has been > >> successfully submitted by Simo Veikkolainen and posted to the > >> IETF repository. > >> > >> Filename: draft-veikkolainen-sip-xmpp-coex-reqs > >> Revision: 02 > >> Title: Requirements and Use Cases for > >> Combining SIP Based Real-time Media Sessions With XMPP Based > >> Instant Messaging and Presence Service. > >> Creation_date: 2011-01-26 > >> WG ID: Independent Submission > >> Number_of_pages: 8 > >> > >> Abstract: > >> This memo defines use cases and requirements for combining Session > >> Initiation Protocol (SIP) based real-time media sessions with > >> Extensible Messaging and Presence Protocol (XMPP) based instant > >> messaging and presence services in a seamless manner. > >> > >> > >> > >> > >> The IETF Secretariat. > >> > >> > >> _______________________________________________ > >> sixpac mailing list > >> sixpac@ietf.org > >> https://www.ietf.org/mailman/listinfo/sixpac > >> > >_______________________________________________ > >sixpac mailing list > >sixpac@ietf.org > >https://www.ietf.org/mailman/listinfo/sixpac > =