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

From: <[email-masked]>
Date: Tue, 1 Feb 2011 11:36:58 +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: [email-masked] [mailto:[email-masked]] On Behalf
>Of ext Elwell, John
>Sent: 27 January, 2011 12:09
>To: Veikkolainen Simo (Nokia-MS/Helsinki); [email-masked]
>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: [email-masked]
>> [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> Sent: 26 January 2011 20:20
>> To: [email-masked]
>> 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:[email-masked]]
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sixpac
>>
>_______________________________________________
>sixpac mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sixpac

---

From: <[email-masked]>
Date: Tue, 1 Feb 2011 11:47:52 +0000

Hi all,

Simo Veikkolainen wrote:
>
>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-xmpp-coex-reqs-02.txt
>
>The changes in this version address the comments made by Peter Musgrave
>(mainly clarifications):
>

It would be good if we got a few more reviews on this requirements and use cases draft to see that we agree on them. So far we have reviews done by Peter Musgrave and John Elwell (in addition to the authors), but in the IETF 79 ad hoc meeting, and on the DISPATCH list, there were quite a few other interested people as well.

So, please review the draft and send your comments. Based on those we can do a couple of revisions, and if after that there is a consensus on the requirements and use cases, we can move to the next phase and start the real work on protocol (extension) proposals.

Markus

---

From: <[email-masked]>
Date: Tue, 1 Feb 2011 11:59:47 +0000

Hi,

>From requirements and user experience perspective this should be symmetric, so I would agree adding that to the requirements.

The actual protocol realization may be more challenging. In the SIXPAC "model" presence information is exchanged via XMPP. So, if a SIXPAC client knows an XMPP address, it can conveniently use presence to learn about the corresponding SIP address (using the envisioned presence data extensions). But if the SIXPAC client knows a SIP address to start with, what would be preferred way for learning the corresponding XMPP address? Would SIP OPTIONS be a good approach? That's the only realistically deployable method that I can think of. Can we assume OPTIONS would work at least to a reasonable extent between SIP UAs in current SIP deployments? (On paper it does, but unfortunately we always need to ask this question due to the deployment realities...)

Markus

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 2 Feb 2011 08:48:06 +0100

I see now, this was meant to be a requirement to obtain the XMPP address WITHOUT establishing a SIP call. If a SIP call were to be established, that would be covered by REQ-2 (although expressed slightly differently there).

So the question is whether, without making a SIP call, there should be a requirement to be able to discover the XMPP address. I don't have a strong opinion, but it certainly sounds reasonable to require this - I could check your presence status or send you an IM without calling you.

Concerning the solution space, OPTIONS might indeed be one method. For example, if Call-Info were used to exchange the address during a call, it could also be exchanged in OPTIONS. There is little else, unless we have an event package, which seems unnecessarily complex.

John

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 01 February 2011 12:00
> To: Elwell, John; [email-masked]; [email-masked]
> Subject: Resolving SIP/XMPP URIs
> 
> Hi,
> 
> John Elwell wrote:
> >
> From requirements and user experience perspective this should 
> be symmetric, so I would agree adding that to the requirements.
> 
> The actual protocol realization may be more challenging. In 
> the SIXPAC "model" presence information is exchanged via 
> XMPP. So, if a SIXPAC client knows an XMPP address, it can 
> conveniently use presence to learn about the corresponding 
> SIP address (using the envisioned presence data extensions). 
> But if the SIXPAC client knows a SIP address to start with, 
> what would be preferred way for learning the corresponding 
> XMPP address? Would SIP OPTIONS be a good approach? That's 
> the only realistically deployable method that I can think of. 
> Can we assume OPTIONS would work at least to a reasonable 
> extent between SIP UAs in current SIP deployments? (On paper 
> it does, but unfortunately we always need to ask this 
> question due to the deployment realities...)
> 
> Markus
>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 02 Feb 2011 10:34:51 +0200

Hey folks,

На 02.02.11 09:48, Elwell, John написа:
> I see now, this was meant to be a requirement to obtain the XMPP
> address WITHOUT establishing a SIP call. If a SIP call were to be
> established, that would be covered by REQ-2 (although expressed
> slightly differently there).
> 
> So the question is whether, without making a SIP call, there should
> be a requirement to be able to discover the XMPP address. I don't
> have a strong opinion, but it certainly sounds reasonable to require
> this - I could check your presence status or send you an IM without
> calling you.

Retrieving an XMPP URI from a SIP one _without_ a previous call seems
somewhat exotic to me. I'd therefore say that allowing for OPTIONS the
same headers that would otherwise carry XMPP URIs during call would be
more than enough, and so be it if this doesn't always work.

Cheers,
Emil

> Concerning the solution space, OPTIONS might indeed be one method.
> For example, if Call-Info were used to exchange the address during a
> call, it could also be exchanged in OPTIONS. There is little else,
> unless we have an event package, which seems unnecessarily complex.
> 
> John
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] Sent: 01 February 2011 12:00 To:
>> Elwell, John; [email-masked]; [email-masked] Subject:
>> Resolving SIP/XMPP URIs
>> 
>> Hi,
>> 
>> John Elwell wrote:
>>> 
>>> 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
>> From requirements and user experience perspective this should be
>> symmetric, so I would agree adding that to the requirements.
>> 
>> The actual protocol realization may be more challenging. In the
>> SIXPAC "model" presence information is exchanged via XMPP. So, if a
>> SIXPAC client knows an XMPP address, it can conveniently use
>> presence to learn about the corresponding SIP address (using the
>> envisioned presence data extensions). But if the SIXPAC client
>> knows a SIP address to start with, what would be preferred way for
>> learning the corresponding XMPP address? Would SIP OPTIONS be a
>> good approach? That's the only realistically deployable method that
>> I can think of. Can we assume OPTIONS would work at least to a
>> reasonable extent between SIP UAs in current SIP deployments? (On
>> paper it does, but unfortunately we always need to ask this 
> _______________________________________________ sixpac mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/sixpac
> 

-- 
Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator
[email-masked]                     PHONE: +33.1.77.62.43.30
http://sip-communicator.org                    FAX:   +33.1.77.62.47.31

---

From: <[email-masked]>
Date: Thu, 3 Feb 2011 13:40:27 +0000

> From: ext Emil Ivov [mailto:[email-masked]]
> Sent: 02 February, 2011 10:35
> To: Elwell, John
> Cc: Isomaki Markus (Nokia-CIC/Espoo); Veikkolainen Simo (Nokia-
> MS/Helsinki); [email-masked]
> Subject: Re: [sixpac] Resolving SIP/XMPP URIs
> 
> Hey folks,
> 

I would also assume that the usual pattern is that you subscribe to XMPP presence and learn the SIP address that way.

But, as long as the requirement is concerned, would everyone be happy with this text:

         It must be possible for a user, who only knows another
         user’s SIP URI, to learn the other user’s XMPP URI, and
	   vice versa.

Regards,
Simo

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 3 Feb 2011 18:29:45 +0100

One scenario would be a user who has only a telephone number. That could be used to make a call to the other user, but it might be preferred to look at presence or send an IM first.

I agree this is perhaps not a very common situation. When only a telephone number is available, it tends to be for somebody outside one's organization, and probably presence / IM would not be available anyway.

Perhaps this is just a desirable, not a firm requirement. I will go with the majority.

John 

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 03 February 2011 13:40
> To: [email-masked]; Elwell, John
> Cc: [email-masked]; [email-masked]
> Subject: RE: [sixpac] Resolving SIP/XMPP URIs
> 
> I would also assume that the usual pattern is that you 
> subscribe to XMPP presence and learn the SIP address that way.
> 
>          user's SIP URI, to learn the other user's XMPP URI, and
> 	   vice versa.
> 
> 
> Regards,
> Simo
> 
> > Cheers,
> > Emil
> >

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 08 Feb 2011 20:16:17 +0100

I think it is important that the capability to do XMPP messaging with a 
SIP endpoint is expressed in regular SIP ways, so that capability 
checking for that function even can be done before a session is 
initiated, and also during session initiation. E.g. the functionality 
should have the possibility to influence the outcome of caller 
preferences - callee capabilities interrogations (RFC 3840, RFC 3841 ).

It seems to me that that is easily achieved, but that is not the issue 
at the moment, when collecting requirements.
I cannot find exactly that need described in the current requirements, 
so I suggest to add a requirement like this:

REQ-x: The capability or preference to initiate and accept XMPP messages 
must be possible to express and interrogate by the standard mechanisms 
for such functions in SIP for caller preferences and callee 
capabilities. ( RFC 3840, RFC 3841 etc.)

Use case: Alice want to call Bob to have his view of some new poems she 
has written. She has a SIP phone with XMPP chat addition. She makes sure 
that her phone expresses a preference for audio and text messaging in 
the call. Bob has two phones registered on his address. One only with 
audio functionality, the other with both audio and text messaging. The 
SIP server can match the Alice's preferences with the capabilities of 
Bob's phones, and direct the call to the device where he can receive and 
read the poems and comment them in their voice conversation.

---

I am not sure if similar standardised features are available for XMPP so 
that it is relevant to express the symmetric requirements on the XMPP side.

Gunnar

______________________________________________________________________________--
[email-masked] skrev 2011-01-26 21:20:
> 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-xmpp-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.
>
> 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
>
>
> 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.
>
> Title:		 Requirements and Use Cases for Combining SIP Based Real-time Media Sessions With XMPP Based Instant Messaging and Presence Service.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Feb 2011 12:13:02 +0100

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:[email-masked] 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

> Sent: 01 February 2011 11:37
> Subject: RE: [sixpac] FW: New Version Notification for 
> [mailto:[email-masked]] On Behalf
> >Of ext Elwell, John