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

<Simo.Veikkolainen@nokia.com> Fri, 28 January 2011 07:27 UTC

Return-Path: <Simo.Veikkolainen@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 E54A93A6A96 for <sixpac@core3.amsl.com>; Thu, 27 Jan 2011 23:27:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[AWL=-1.849, 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 qe0qz0NUaZfr for <sixpac@core3.amsl.com>; Thu, 27 Jan 2011 23:27:51 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id C6C2D3A6A67 for <sixpac@ietf.org>; Thu, 27 Jan 2011 23:27:48 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0S7UX5k004435; Fri, 28 Jan 2011 09:30:52 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Jan 2011 09:30:36 +0200
Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 28 Jan 2011 08:30:36 +0100
Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.211]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi; Fri, 28 Jan 2011 08:30:35 +0100
From: <Simo.Veikkolainen@nokia.com>
To: <john.elwell@siemens-enterprise.com>, <sixpac@ietf.org>
Thread-Topic: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02
Thread-Index: AQHLvgoy0wIpnEKqE06V6/QWfLMz+JPl+cAw
Date: Fri, 28 Jan 2011 07:30:33 +0000
Message-ID: <F9E2FDAF48D4544F874A56A3A8BD68B1F8C016@008-AM1MPN1-003.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: 28 Jan 2011 07:30:36.0581 (UTC) FILETIME=[416ADD50:01CBBEBD]
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: Fri, 28 Jan 2011 07:27:53 -0000

Thanks for the comments John! See below.

> -----Original Message-----
> From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com]
> 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....".

Changed.
 
> 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."

Changed.
 
> 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."

Agree your text captures the point better. Now looking at the text, I'm not sure the "integrated" vs. "separated" endpoint was a very good choice. Might need to think of a better alternative.

> 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?

Changed.

> 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?

You're right, probably there is no reason for this to be asymmetrical. Added simply "and vice versa." to this requirement.

Simo

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