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
>