Re: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02
<Markus.Isomaki@nokia.com> Tue, 01 February 2011 11:33 UTC
Return-Path: <Markus.Isomaki@nokia.com>
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 <sixpac@core3.amsl.com>; 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 <sixpac@core3.amsl.com>; 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 <sixpac@ietf.org>; 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: Markus.Isomaki@nokia.com
To: john.elwell@siemens-enterprise.com, Simo.Veikkolainen@nokia.com, sixpac@ietf.org
Thread-Topic: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02
Thread-Index: AQHLvZTBMsVG7EQwQ06Q+aXi3KtO9ZPjrp/wgADIKnCACBBjAA==
Date: Tue, 01 Feb 2011 11:36:58 +0000
Message-ID: <DD8B10B86502AB488CB2D3DB4C546E38E67F7D@008-AM1MPN1-004.mgdnok.nokia.com>
References: <F9E2FDAF48D4544F874A56A3A8BD68B13BC79A@008-AM1MPN1-003.mgdnok.nokia.com> <A444A0F8084434499206E78C106220CA06A858780C@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA06A858780C@MCHP058A.global-ad.net>
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." <sixpac.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sixpac>, <mailto:sixpac-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sixpac>
List-Post: <mailto:sixpac@ietf.org>
List-Help: <mailto:sixpac-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sixpac>, <mailto:sixpac-request@ietf.org?subject=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/most 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
- [sixpac] FW: New Version Notification for draft-v… Simo.Veikkolainen
- Re: [sixpac] FW: New Version Notification for dra… Elwell, John
- Re: [sixpac] FW: New Version Notification for dra… Simo.Veikkolainen
- Re: [sixpac] FW: New Version Notification for dra… Markus.Isomaki
- Re: [sixpac] FW: New Version Notification for dra… Markus.Isomaki
- [sixpac] Resolving SIP/XMPP URIs Markus.Isomaki
- Re: [sixpac] Resolving SIP/XMPP URIs Elwell, John
- Re: [sixpac] Resolving SIP/XMPP URIs Emil Ivov
- Re: [sixpac] Resolving SIP/XMPP URIs Simo.Veikkolainen
- Re: [sixpac] Resolving SIP/XMPP URIs Elwell, John
- [sixpac] Capability and preference expression and… Gunnar Hellström
- Re: [sixpac] FW: New Version Notification for dra… Elwell, John
- Re: [sixpac] Capability and preference expression… Gunnar Hellström
- Re: [sixpac] Capability and preference expression… Joe Hildebrand
- Re: [sixpac] Capability and preference expression… Simo.Veikkolainen
- Re: [sixpac] Capability and preference expression… Gunnar Hellström
- Re: [sixpac] Capability and preference expression… Simo.Veikkolainen
- Re: [sixpac] Capability and preference expression… Gunnar Hellström