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, 1 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