Re: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02

"Elwell, John" <john.elwell@siemens-enterprise.com> Thu, 27 January 2011 10:05 UTC

Return-Path: <john.elwell@siemens-enterprise.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 D8F3E28C137 for <sixpac@core3.amsl.com>; Thu, 27 Jan 2011 02:05:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.426
X-Spam-Level:
X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 8rZQqCO-XmOC for <sixpac@core3.amsl.com>; Thu, 27 Jan 2011 02:05:39 -0800 (PST)
Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A6E1428C12F for <sixpac@ietf.org>; Thu, 27 Jan 2011 02:05:38 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3163507; Thu, 27 Jan 2011 11:08:40 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 8BA5A23F0278; Thu, 27 Jan 2011 11:08:40 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 27 Jan 2011 11:08:40 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "Simo.Veikkolainen@nokia.com" <Simo.Veikkolainen@nokia.com>, "sixpac@ietf.org" <sixpac@ietf.org>
Date: Thu, 27 Jan 2011 11:08:39 +0100
Thread-Topic: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02
Thread-Index: AQHLvZTBMsVG7EQwQ06Q+aXi3KtO9ZPjrp/wgADIKnA=
Message-ID: <A444A0F8084434499206E78C106220CA06A858780C@MCHP058A.global-ad.net>
References: <F9E2FDAF48D4544F874A56A3A8BD68B13BC79A@008-AM1MPN1-003.mgdnok.nokia.com>
In-Reply-To: <F9E2FDAF48D4544F874A56A3A8BD68B13BC79A@008-AM1MPN1-003.mgdnok.nokia.com>
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." <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: Thu, 27 Jan 2011 10:05:40 -0000

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
>