Re: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02
"Elwell, John" <john.elwell@siemens-enterprise.com> Thu, 10 February 2011 11:12 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 224333A6985 for <sixpac@core3.amsl.com>; 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 <sixpac@core3.amsl.com>; 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 <sixpac@ietf.org>; 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" <john.elwell@siemens-enterprise.com>
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>, "Simo.Veikkolainen@nokia.com" <Simo.Veikkolainen@nokia.com>, "sixpac@ietf.org" <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: <A444A0F8084434499206E78C106220CA06C2A195D2@MCHP058A.global-ad.net>
References: <F9E2FDAF48D4544F874A56A3A8BD68B13BC79A@008-AM1MPN1-003.mgdnok.nokia.com> <A444A0F8084434499206E78C106220CA06A858780C@MCHP058A.global-ad.net> <DD8B10B86502AB488CB2D3DB4C546E38E67F7D@008-AM1MPN1-004.mgdnok.nokia.com>
In-Reply-To: <DD8B10B86502AB488CB2D3DB4C546E38E67F7D@008-AM1MPN1-004.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, 10 Feb 2011 11:12:54 -0000
I took a look again (sorry for the delay). It looks like a good basis. I can imagine the biggest discussion will be on the subject of the SIP session identifier. We need something that stands a reasonable chance of getting through 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 header field. John > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: 01 February 2011 11:37 > To: Elwell, John; Simo.Veikkolainen@nokia.com; sixpac@ietf.org > Subject: RE: [sixpac] FW: New Version Notification for > draft-veikkolainen-sip-xmpp-coex-reqs-02 > > 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